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Foreword 
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This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the interface between the Universal ICC (UICC) and the Mobile Equipment (ME), and 
mandatory ME procedures, specifically for "USIM Application Toolkit". 

US AT is a set of commands and procedures for use during the network operation phase of 3G, in addition to those 
defined in TS 31.101 [13]. 

Specifying the interface is to ensure interoperability between a UICC and an ME independently of the respective 
manufacturers and operators. 

The present document defines: 

the commands; 

the application protocol; 

the mandatory requirements on the UICC and ME for each procedure. 

The present document does not specify any aspects related to the administrative management phase. Any internal 
technical realization of either the UICC or the ME are only specified where these reflect over the interface. The present 
document does not specify any of the security algorithms which may be used. 
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3 Definitions, abbreviations and symbols 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in 3G TS 21.905 and the following 
apply: 
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application: application consists of a set of security mechanisms, files, data and protocols (excluding transmission 
protocols). 

application protocol: set of procedures required by the application. 

bearer independent protocol: mechanism by which the ME provides the UICC with access to the data bearers 
supported by the ME and the network. 

card session: link between the card and the external world starting with the ATR and ending with a subsequent reset or 
a deactivation of the card. 

card x: additional card. 

card reader x: electrical interface to support additional card. 

data channel: allow the UICC and the network to exchange data using a selected bearer. 

data object: information seen at the interface for which are defined a tag (identifier), a length and a value. Data objects 
can be either BER-TLV (objects that conform to the Basic Encoding Rules of ASN.l) or SIMPLE-TLV. In the present 
document, all BER-TLV data objects are "primitive": the value part consists only of SIMPLE-TLV data objects. 

link: radio resource. 

padding: one or more bits appended to a message in order to cause the message to contain the required number of bits 
or bytes. 

proactive UICC: UICC which is capable of issuing commands to the ME. 

proactive UICC session: sequence of related US AT commands and responses. A proactive UICC session starts with 
the status response '91 xx' (proactive command pending) and ends with a status response of '90 00' (normal ending of 
command) after Terminal Response. 

Rx buffer: dedicated memory used to temporarily store data to be retrieved. 

Service data unit (SDU): In layered systems, a set of data that is sent by a user of the services of a given layer, and is 
transmitted to a peer service user semantically unchanged. A Protocol Control Information (PCI) header is attached to 
the Service Data Unit (SDU) by the layer to form a Protocol Data Unit (PDU). 

Tx buffer: dedicated memory used to temporarily store data to be sent. 

UICC application session: execution of a sequence of commands internal to the UICC that can result in the 
performance of one or several proactive UICC sessions. The UICC application session can be started by any event in 
the card session, and can execute for the duration of the card session. Processing of the UICC application session will 
not interfere with normal 3G operation. 

USAT: set of applications and related procedures that may be used during a 3G session. 

3.2 Abbreviations 

For the purpose of the present document, the following abbreviations apply: 

ADN Abbreviated Dialling Number 

APDU Application Protocol Data Unit 

ATR Answer To Reset 

BCD Binary Coded Decimal 

BD_ADDR Bluetooth Device address 

BDN Barred Dialling Number 

BER Basic Encoding Rules of ASN.l 

C-APDU Command Application Protocol Data Unit 

CB Cell Broadcast 

CBMI Cell Broadcast Message Identifier 

CCP Capability/Configuration Parameter 

CoD Class Of Device (Bluetooth related) 

CSD Circuit Switched Data 
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DTMF Dual Tone Multiple Frequency 

EF Elementary File 

EGPRS EDGE General Packet Radio Service 

EIA Electronics Industries Association 

ETSI European Telecommunications Standards Institute 

etu elementary time unit 

FDN Fixed Dialling Number 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

ID IDentifier 

lEC International Electrotechnical Commission 

IMEI International Mobile Equipment Identity 

IMSI International Mobile Subscriber Identity 

ISO International Organization for Standardization 

Igth The (specific) length of a data unit 

LND Last Number Dialled 

ME Mobile Equipment 

MMI Man Machine Interface 

NMR Network Measurement Results (see also 3G 24.008 [9]) 

NPI Numbering Plan Identifier 

PDN Packet Data Network 

PDP Packet Data Protocol, e.g., Ip or X25 or PPP 

PDU Protocol Data Unit 

RAND A RANDom challenge issued by the network 

R-APDU Response Application Protocol Data Unit 

RFU Reserved for Future Use 

SDP Service Discovery Protocol (Bluetooth related) 

SDU Service Data Unit 

SMS Short Message Service 

SRES Signed RESponse calculated by a UICC 

SS Supplementary Service 

SSC Supplementary Service Control string 

SW1/SW2 Status Word 1 / Status Word 2 

TCP Transmission Control Protocol 

TE Terminal Equipment (e.g. an attached personal computer) 

TIA Telecommunications Industries Association 

TLV Tag, length, value 

TON Type Of Number 

TP Transfer layer Protocol 

TS Technical Specification 

UDP User Datagram Protocol 

UCS2 Universal two byte coded Character Set 

UE User Equipment 

UICC USIM Integrated Circuit Card 

UMTS Universal Mobile Telecommunication System 

URL Uniform Resource Location 

USAT USIM Application Toolkit 

USIM Universal Subscriber Identity Module 

USSD Unstructured Supplementary Service Data 



3.3 Symbols 



For the purposes of the present document, the following symbols apply: 
'0' to '9' and 'A' to 'F' The sixteen hexadecimal digits 
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Overview of USAT 



The USAT provides mechanisms which allow applications, existing in the UICC, to interact and operate with any ME 
which supports the specific mechanism(s) required by the application. 

If class "a" is supported, a UICC supporting USAT shall be able to communicate with the additional card(s) and get 
information about the additional reader(s) via the ME. 

The following mechanisms have been defined. These mechanisms are dependent upon the commands and protocols 
relevant to USAT in TS 31.101 [13]. 

4.1 Profile Download 

Profile downloading provides a mechanism for the ME to tell the UICC what it is capable of 

4.2 Proactive UICC 

Proactive UICC gives a mechanism whereby the UICC can initiate actions to be taken by the ME. These actions 
include: 

displaying text from the UICC to the ME; 

sending a short message; 

setting up a voice call to a number held by the UICC; 

setting up a data call to a number and bearer capabilities held by the UICC; 

sending a SS control or USSD string; 

- playing tone in earpiece; 
initiating a dialogue with the user; 

USIM initialization request and notification of changes to EF(s); 

- providing local information from the ME to the UICC; 
communicating with the additional card(s) (if class "a" is supported); 

- providing information about the additional card reader(s) (if class "a" is supported); 
managing timers running physically in the ME; 

- running an AT command received from the UICC, and returning the result to the UICC (if class "b" is 
supported); 

- sending DTMF; 

- requesting the ME to launch the browser corresponding to a URL. (if class "c" is supported); 

establishing and managing a bearer independent protocol (if class "e" is supported). 

For each command involved in the dialog with the user, a help information may be available, either for each item of a 
list of items proposed to the user, or with each command requesting a response from the user. If a proactive command 
involved in the dialog with the user indicates the availability of the help feature, the support of this feature is optional 
for the ME. 
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4.3 Data download to UICC 

Data downloading to the UICC uses either dedicated commands (the transport mechanisms of SMS point-to-point and 
Cell Broadcast) or the Bearer independent protocol. Transferral of information over the UICC-ME interface uses the 
ENVELOPE command. 

4.4 Menu selection 

A set of possible menu entries is supplied by the UICC in a proactive UICC command. The menu selection mechanism 
is used to transfer the UICC application menu item which has been selected by the user to the UICC. The menu 
selection mechanism may also be used for requesting help information on the items of the UICC application menu. 

4.5 Call control by USIM 

When this service is activated by the USIM, all dialled digit strings, supplementary service control strings and USSD 
strings are first passed to a USIM application before the ME sets up the call, the supplementary service operation or the 
USSD operation. The ME shall also pass to the USIM application at the same time its current serving cell. The USIM 
application has the ability to allow, bar or modify the call, the supplementary service operation or the USSD operation. 
The USIM application also has the ability to replace a call request, a supplementary service operation or a USSD 
operation by another call request or supplementary service operation or USSD operation. For example, a call request 
can be replaced by a supplementary service operation or a USSD operation, and vice-versa. 

4.6 MO Short Message control by USIM 

When this service is activated by the USIM, all MO short messages are first passed to the USIM application before the 
ME sends the short message. The ME shall also pass to the USIM application at the same time its current serving cell. 
The USIM application shall have the ability to allow the sending, bar the sending or modify the destination address of 
the short message before sending it. 

4.7 Event download 

A set of events to monitor for is supplied by the UICC in a proactive UICC command. The event download mechanism 
is used to transfer details of the event to the UICC, when it occurs. Events that the ME can report to the UICC include 
incoming calls, location status, access technology, display parameters changed, and availability of the screen for 
applications. 



4.8 Security 



Applications designed using the features in the present document may require methods to ensure data confidentiality, 
data integrity, and data sender validation, or any subset of these. Requirements for these mechanisms are defined in 
clause 11. 

4.9 Multiple card 

This subclause applies only if class "a" is supported. 

One event and a set of proactive commands are supplied to monitor and control Card x behaviour. 



4.10 Timer Expiration 



The UICC is able to manage timers running physically in the ME with a proactive command. The Timer Expiration 
mechanism is used to inform the UICC when a timer expires. 
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4.1 1 Bearer Independent Protocol 

The following paragraph applies if class "e" is supported. 

The set of proactive commands (OPEN CHANNEL, CLOSE CHANNEL, SEND DATA, RECEIVE DATA and GET 
CHANNEL STATUS) and events (Data available, Channel status) allows the UICC to estabhsh a data channel with the 
ME, and through the ME either to a remote Server in the Network or to a remote device in the Personal Area Network. 
The UICC provides information for the ME to select an available bearer at the time of channel establishment. The ME 
then allows the UICC and the Server to exchange data on this channel, transparently. The SIM uses service of ME 
lower layer to send data by providing Service Data Unit to ME. The default lower layer is the higher layer of selected 
bearer. 

The following paragraphs apply if class "f is supported. 

The proactive command SERVICE SEARCH allows the UICC to look for services available on remote devices. The 
proactive command GET SERVICE INFORMATION allows the UICC to get detailed information regarding one 
service. 

The proactive command DECLARE SERVICE allows the UICC to add or delete a service to the ME service database. 
The event Local Connection allows to inform the UICC of a connection request on a local bearer. 



Profile download 



5.1 Procedure 

The profile download instruction is sent by the ME to the UICC as part of the UICC initialization procedure. This 
procedure is specified in TS 3L101 [13]. The profile sent by the ME shall state the facilities relevant to USAT that are 
supported by the ME. 

This procedure is important, as it is by this that the UICC knows what the ME is capable of, and the UICC can then 
limit its instruction range accordingly. If no command is sent by the ME, the UICC shall assume that the ME does not 
support USAT. 

5.2 Structure and coding of TERMINAL PROFILE 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data: 



Description 


Subclause 


IM/O/C 


Length 


Profile 


- 


M 


igth 



Profile: 

Contents: The list of USAT facilities that are supported by the ME. 

Coding: 

1 bit is used to code each facility: 

bit = 1 : facility supported by ME 

bit = 0: facility not supported by ME 
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First byte (Download): 



b8 b7 b6 b5 b4 b3 b2 bl 



Profile download 
SMS-PP data download 
Cell Broadcast data download 
Menu selection 

Bit = 1 if SMS-PP data download is supported 
Timer expiration 

Bit = 1 if Call Control by USIM is supported 
"Bit = 1 if Call Control by USIM is supported 



Second byte (Other): 



b7 b6 b5 b4 b3 b2 bl 



Command result 

Call Control by USIM 

Bit = 1 if Call Control by USIM is supported 

MO short message control by USIM 

Bit = 1 if Call Control by USIM is supported 

UCS2 Entry supported 

UCS2 Display supported 

Bit = 1 if Display Text is supported 



Third byte (Proactive UICC): 



b7 b6 b5 b4 b3 b2 bl 



Proact 
Proact 
Proact 
Proact 
Proact 
Proact 
Proact 
Proact 



ive UICC 

ive UICC 

ive UICC 

ive UICC 

ive UICC 

ive UICC 

ive UICC 

ive UICC 



DISPLAY TEXT 
GET INKEY 
GET INPUT 
MORE TIME 
PLAY TONE 
POLL INTERVAL 
POLLING OFF 
REFRESH 



Fourth byte (Proactive UICC): 



b7 b6 b5 b4 bS b2 bl 



Proactive UICC 

Proactive UICC 

"proactive UICC 

Proactive UICC 

"proactive UICC 

Proactive UICC 

"proactive UICC 

LAC, Cell ID & 

"proactive UICC: 



SELECT ITEM 
SEND SHORT MESSAGE 
SEND SS 
SEND USSD 
SET UP CALL 
SET UP MENU 

PROVIDE LOCAL INFORMATION 
IMF I) 
PROVIDE LOCAL INFORMATION 



(MCC, MNC, 
(NMR) 



Fifth byte (Event driven information): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 




















L 


Proact 
Event : 


ive UICC: SET UP EVENT 
MT call 






Event : 


Call connected 






Event : 


Call disconnected 






Event : 


Location status 






Event : 


User activity 






Event : 


Idle screen available 








Event : 


Card reader status 



Sixth byte (Event driven information extensions): 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
























L 


Event 
Event 










Event 












Event 



Language selection 
Browser Termination 
Data available 
Channel status 
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Event: Access technology changed 
Event : Display parameters changed 
Event : Local Connection 
RFU, bit = 



Seventh byte (Multiple card proactive commands) for class "a" 



b8 b7 b6 b5 b4 b3 b2 bl 



Proactive UICC 
"proactive UICC 
Proactive UICC 
Proactive UICC 
status) 

Proactive UICC 
identifier) 
"rfu, bit = 



POWER ON CARD 
POWER OFF CARD 
PERFORM CARD APDU 
GET READER STATUS 

GET READER STATUS 



(Card reader 
(Card reader 



Eighth byte (Proactive UICC): 



b8 b7 b6 b5 b4 b3 b2 bl 



TIMER MANAGEMENT 
TIMER MANAGEMENT 



(start, stop) 
(get current 



Proactive UICC: 

Proactive UICC: 

value) 

Proactive UICC: PROVIDE LOCAL INFORMATION (date, 

time and time zone) 
Bit = 1 if GET INKEY is supported 
SET UP IDLE MODE TEXT 

RUN AT COMMAND (i.e. class "b" is supported) 
Bit = 1 if SETUP CALL by USIM is supported 
Bit = 1 if Call Control by USIM is supported 



Ninth byte: 



b8 b7 b 



b5 b4 b3 b2 bl 



Bit = 1 if DISPLAY TEXT is supported 
SEND DTMF command 

Bit = 1 if Proactive UICC: PROVIDE LOCAL 
INFORMATION (NMR) is supported 



Proactive UICC 

(language) 
Proactive UICC 

Advance) 
Proactive UICC 
Proactive UICC 
Proactive UICC 
Technology) 



PROVIDE LOCAL INFORMATION 

PROVIDE LOCAL INFORMATION (Timing 

LANGUAGE NOTIFICATION 

LAUNCH BROWSER 

PROVIDE LOCAL INFORMATION (Access 



Tenth byte (Soft keys support) for class "d": 



b8 b7 b6 b5 b4 bS b2 bl 



Soft keys support for SELECT ITEM 
Soft Keys support for SET UP MENU 



RFU, 


bit = 


= 


RFU, 


bit = 


= 


RFU, 


bit = 


= 


RFU, 


bit = 


= 


RFU, 


bit = 


= 


RFU, 


bit = 


= 



Eleventh byte: (Soft keys information) 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 

























Maximum number of soft keys available 
' FF ' value is reserved for future use 
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Twelfth byte: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 




UICC: 
UICC: 
UICC: 
UICC: 
UICC: 
UICC: 
UICC: 
UICC: 




















1 


Proactive 


OPEN CHANNEL 




Proactive 


CLOSE CHANNEL 






Proactive 


RECEIVE DATA 






Proactive 


SEND DATA 






Proactive 


GET CHANNEL STATUS 






Proactive 


SERVICE SEARCH 






Proactive 


GET SERVICE INFORMATION 








Proactive 


DECLARE SERVICE 



Thirteenth byte: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



CSD supported by ME 

GPRS supported by ME 

Bluetooth supported by ME 

IrDA supported by ME 

RS232 supported by ME 

Number of channels supported by ME 



Fourteenth byte: (Screen height) 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Number of characters supported down the ME display 

as defined in 5.3.1 

RFU, bit = 

Screen Sizing Parameters supported as defined in 

subclause 5 . 3 



Fifteenth byte: (Screen width) 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 

































Number of characters supported across the ME 
display as defined in 5.3.2 
Variable size fonts Supported 



Sixteenth byte: (Screen effects) 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Display can be resized as defined in 5.3.3 

Text Wrapping supported as defined in 5.3.4 

Text Scrolling supported as defined in 5.3.5 

RFU 

RFU 

Width reduction when in a menu as defined in 5.3.5 



Seventeenth byte: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


TCP 
UDP 






















L 












RFU, 


bit 



Eighteenth byte: 



b8 b7 b 



b5 b4 b3 b2 bl 



Proactive UICC : DISPLAY TEXT (Variable Time out) 
Proactive UICC : GET INKEY (help is supported while 
waiting for immediate response or variable timeout) 
USB supported by ME 



Proactive UICC 
RFU, bit = 
RFU, bit = 
RFU, bit = 
RFU, bit = 



GET INKEY (Variable Timeout) 
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Subsequent bytes: 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



RFU, bit 



RFU bits, and all bits of subsequent bytes, are reserved to indicate future facilities. A SIM supporting only the 
features of SIM Application Toolkit defined here shall not check the value of RFU bits. 

Response parameters/data: None. 

5.3 Definition of display parameters in Profile download 

This subclause defines the terms used for defining the passing of the ME's screen parameters from the ME to the SIM. 

5.3.1 Number of characters supported down the IVIE display 

This is the guaranteed number of characters supported down the ME display without scrolling (using the default 
character set specified in 3G TS 23.038 [4]) as a result of a Display Text Proactive command. 

If the screen resized as defined in subclause 5.3.3 then this value shall be the initial number of characters supported 
before the display can be resized. 

5.3.2 Number of characters supported across the IVIE display 

This is the guaranteed number of characters supported across the ME display without scrolling (using the default 
character set specified in 3G TS 23.038 [4]) as a result of a Display Text Proactive command that can be viewed in one 
instance. 

If the screen resized as defined in subclause 5.3.3 then this value shall be the initial number of characters supported 
before the display can be resized. 

5.3.3 Display can be resized 

Display can be resized is supported if either: 

the user can change the number of characters supported across the display, down the display or both; 

the ME can dynamically change the number of characters supported across the display, down the display or both. 

5.3.4 Text Wrapping 

Text wrapping is supported if the ME puts words that would be split across two lines, due to the display size, at the 
beginning of the next line down. 

5.3.5 Text Scrolling 

Text scrolling is supported if the ME scrolls, on one line, words that would be split across two lines, due to the display 
size. 

5.3.6 Width reduction when in a menu 

This value is the number of characters available across the display due to a DISPLAY TEXT proactive command 
without scrolling (using the default character set specified in 3G TS 23.038 [4]) minus the number of characters 
available across the display due to a SELECT ITEM proactive command without scrolling (using the default character 
set specified in 3G TS 23.038 [4]). 

If the screen resized as defined in subclause 5.3.3 then this value shall be calculated using the initial number of 
characters supported before the display can be resized. 
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6 Proactive UICC 

6.1 Introduction 

TS 31.101 [13] defines that the ME communicates to the UICC using the T=0 or T=l protocols, which are specified in 
ISO/IEC 7816-3 [16]. The ME is always the "master" and initiates commands to the UICC, and therefore there is no 
mechanism for the UICC to initiate a communication with the ME. This limits the possibility of introducing new UICC 
features requiring the support of the ME, as the ME needs to know in advance what actions it should take. 

The UICC shall execute all USAT Proactive commands or procedures in such a way as not to jeopardise, or cause 
suspension, of service provisioning to the user. This could occur if, for example, execution of INTERNAL 
AUTHENTICATE is delayed by internal USAT activity, which would result in the network denying or suspending 
service to the user. Specifically, the MORE TIME command shall be used, whenever possible, to allow the ME access 
to the 3G functionality of the UICC if a USAT application is taking an unreasonable amount of time to complete 
execution. 

NOTE: The maximum work waiting time without sending a MORE TIME command depends on several factors 
(e.g. the permissible duration of a network-UICC authentication); in some cases as little as 2 seconds 
could be required. During this period the UICC should respect the work waiting time procedure, defined 
in TS 31.101 [13]. 

The proactive UICC service provides a mechanism which stays within the T=0 and T=l protocols, but adds a new status 
response word SWl. This status response has the same meaning as the normal ending ('90 00'), and can be used with 
most of the commands that allow the normal ending, but it also allows the UICC to say to the ME "I have some 
information to send to you". The ME then uses the FETCH function to find out what this information is. 

To avoid cross-phase compatibility problems, these functions shall only be used between a proactive UICC and an ME 
that supports proactive UICC commands (see subclause 6.2). 

The UICC can issue a variety of commands through this mechanism, given in alphabetical order: 

CLOSE CHANNEL: which requests the ME to close the specified data channel (if class "e" is supported); 

- DECLARE SERVICE: which requests the ME to add or remove a service from its service database (the list of 
the resources available through a local bearer), (if class "f is supported) 

- DISPLAY TEXT: which displays text or an icon on screen. A high priority is available, to replace anything else 
on screen; 

GET CHANNEL STATUS: which requests the ME to return the current status of all available data channels (if 
class "e" is supported); 

GET INKEY: which sends text or an icon to the display and requests a single character response in return. It is 
intended to allow a dialogue between the UICC and the user, particularly for selecting an option from a menu; 

GET INPUT: which sends text or an icon to the display and requests a response in return. It is intended to allow 
a dialogue between the UICC and the user; 

GET READER STATUS: which gives information about the additional reader(s) and inserted card(s) (Card x 
state, e.g. powered on or not. Card x Presence), if class "a" is supported; 

GET SERVICE INFORMATION: which requests the ME to look for detailed information on a given service 
on a given device (if class "f is supported). 

- LANGUAGE NOTIFICATION: which allows the UICC to notify the ME about the currently used language in 
text strings issued by the USAT application; 

LAUNCH BROWSER: which requests a browser inside a browser enabled ME to interpret the content 
corresponding to an URL; 

- MORE TIME: which does not request any action from the ME. The ME is required to respond with 

TERMINAL RESPONSE (OK) as normal - see below. The purpose of the MORE TIME command is to provide 
a mechanism for the USAT task in the UICC to request more processing time; 
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OPEN CHANNEL: which requests the ME to open a data channel with parameters indicated in the command 
(if class "e" is supported); 

- PERFORM CARD APDU: which requests the ME to send an APDU command to the additional card, if class 
"a" is supported. This command is compatible with any protocol between the ME and the additional card; 

PLAY TONE: which requests the ME to play a tone in its earpiece, ringer, or other appropriate loudspeaker; 

- POLL INTERVAL: which negotiates how often the ME sends STATUS commands to the UICC during idle 
mode. Polling is disabled with POLLING OFF. Use of STATUS for the proactive UICC is described in 

TS 31.101 [13]; 

POWER OFF CARD: which closes the session with the additional card, if class "a" is supported; 

POWER ON CARD: which initiates a session with the additional card and returns all the ATR bytes, if class 
"a" is supported; 

- PROVIDE LOCAL INFORMATION: which requests the ME to pass local information to the UICC, for 
example the mobile country and network codes (MCC + MNC) of the network on which the user is registered; 

RECEIVE DATA: which requests the ME to return to the UICC data received on the specified channel (if class 
"e" is supported); 

REFRESH: which requests the ME to carry out an initialization, and/or advises the ME that the contents or 
structure of EFs on the UICC have been changed. The command also makes it possible to restart a card session 
by resetting the UICC; 

RUN AT COMMAND: which will convey an AT Command to the ME, and cause the response to the AT 
Command to be returned to the UICC; 

SELECT ITEM: where the UICC supplies a list of items, and the user is expected to choose one. The ME 
presents the list in an implementation-dependent way; 

SEND DATA: which requests the ME to send on the specified channel data provided by the UICC (if class "e" 
is supported); 

SEND DTMF: which requests the ME to send DTMF tone(s) during an established call; 

- SEND SHORT MESSAGE: which sends a short message or SMS-COMMAND to the network; 
SEND SS: which sends an SS request to the network; 

- SEND USSD: which sends a USSD string to the network; 

SERVICE SEARCH: which requests the ME to look for services available in the ME environment (if class "f 
is supported). 

SET UP CALL: of which there are three types: 

set up a call, but only if not currently busy on another call; 

set up a call, putting all other calls (if any) on hold; 

set up a call, disconnecting all other calls (if any). 

SET UP EVENT LIST: where the UICC supplies a list of events which it wants the ME to provide details of 
when these events happen; 

- SET UP IDLE MODE TEXT: which supplies a text string to be used by the ME as stand-by mode text; 

SET UP MENU: where the UICC supplies a list of items to be incorporated into the ME's menu structure; 

TIMER MANAGEMENT: which requests the ME to manage a timer in a way described in the command 
(start, deactivate and get the current value) and, in the case of starting a timer, for a duration indicated in the 
command. 



£75/ 



3GPP TS 31 .1 1 1 version 4.3.0 Release 4 23 ETSI TS 1 31 1 1 1 V4.3.0 (2001 -06) 

The ME tells the UICC if the command was successful or not using the command result procedure defined in 
subclause 6.7. Responsibility for what happens after that (whether to repeat the command, try another one immediately, 
try again sometime later, or not to try again at all) lies with the USAT. However, the USAT needs to know why the 
command failed, so the ME provides the UICC with the result of the command. 

Results are grouped into three main types: 

- OK; 

temporary problem. These results are further broken down into types of temporary problems, and specific 
causes. Generally, they indicate to the UICC that it may be worth trying again; 

- permanent problem. These results are again further broken down into types of permanent problems, and specific 
causes. Generally, they indicate to the UICC that it is not worth trying again during this 3G session. 

If the UICC issues an instruction to the ME to initiate a Mobile Originated transaction (e.g. SEND SMS, SEND USSD 
or SEND DTMF), then unless explicitly stated elsewhere in the present document or in TS 31.101 [13], the content 
supplied by the UICC for onward transmission by the ME shall not be altered by the ME. 



6.2 Identification of IVIE support 



An ME that supports proactive UICCs shall be identified as such when it sends a TERMINAL PROFILE command 
during UICC initialization. A proactive UICC shall not send any command requests (status bytes SWl SW2 = '91 XX') 
to a mobile that does not support the proactive UICC feature. 



6.3 General procedure 



For all of the procedures that can end in '90 00' (indicating normal ending to the command) a proactive UICC operating 
with an ME that supports proactive UICCs may instead use the status response '91 XX'. 

The response code '91 XX' shall indicate to the ME that the previous command has been successfully executed by the 
UICC in the same way as '90 00' (i.e. "OK"), but additionally it shall indicate response data which contains a command 
from the UICC for a particular ME procedure (defined in subclause 6.4). 

The value 'XX' indicates the length of the response data. The ME shall use the FETCH command to obtain this data. 

It is the responsibility of the UICC to remind the ME of a pending proactive command by applying the '91 XX' 
returncode until it is fetched by the ME. 

NOTE 1 : The last value of 'XX' received in a '9 1 XX' return code from the UICC should be used by the ME in a 
following FETCH command. 

NOTE 2: It is recommended that the ME interprets a '90 00' following a '91 XX' without a corresponding FETCH 
as if no proactive command is available in the UICC and regard the proactive UICC session as being 
terminated. However, the UICC should be able to handle a FETCH command being sent in this case, e.g. 
by applying the appropriate error handling (cf. "Handhng of unknown, unforeseen and erroneous 
messages"). 

TS 31.101 [13] shows how the UICC can initiate a proactive command. 

When the ME has received a command from the UICC, it shall attempt to process the command immediately. 

If the command has been successfully executed, the ME shall inform the UICC as soon as possible, using 
TERMINAL RESPONSE. 

If the command was not successfully executed, the ME shall inform the UICC as soon as possible using 
TERMINAL RESPONSE with an error condition. 

Responsibility for re-trying lies with the UICC application. The USAT can make a judgement whether to send the same 
command again, to send a different one, or not to try again, from the information given by the ME in TERMINAL 
RESPONSE. If the UICC application wishes the ME to try again, it shall issue a new (identical) command. 

Only one proactive command can be ongoing at any one time. 
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6.4 Proactive UICC commands and procedures 

6.4.1 DISPLAY TEXT 

This command instructs the ME to display a text message, and/or an icon (see subclause 6.5.4). It allows the UICC to 
define the priority of that message, and the text string format. 

Two types of priority are defined: 

display normal priority text and/or icon on screen; 

display high priority text and/or icon on screen. 
The text string can be in one of three formats: 

- packed format in SMS default alphabet - (see subclause 8.15.2); 
unpacked format in SMS default alphabet - (see subclause 8.15.2); 
UCS2 alphabet format - (see subclause 8.15.3). 

NOTE 1: The text string may contain up to 240 bytes. 

A flag (see command qualifier, subclause 8.6) shall be set to inform the ME whether the availability of the screen for 
subsequent information display after its use for 'Display Text' should be either after a short delay (the duration of the 
delay being at the discretion of the ME manufacturer unless an exact duration is indicated by a duration object), or 
following a user MMI action. 

An immediate response object may be included by the UICC, to indicate if the ME should sustain the display beyond 
sending the TERMINAL RESPONSE. ME support of this feature is indicated in the PROFILE DOWNLOAD. The 
behaviour of non-supporting MEs is dependent on the Comprehension Required flag. 

A duration object that represents the variable display timeout may be included by the UICC. The duration informs the 
ME about the required duration of the display (Precision and resolution are in accordance with subclause 6.4.21 Timer 
Management). The requested timeout value replaces the timeout set by the ME manufacturer. ME support of this feature 
is indicated in the PROFILE DOWNLOAD. The behaviour of MEs that do not support this feature is dependent on the 
Comprehension Required flag. 

If the user has indicated the need to end the proactive UICC application session, the ME shall send a 
TERMINAL RESPONSE with "Proactive UICC application session terminated by the user" result value. 

If the user has indicated the need to go backwards in the proactive UICC application session, the ME shall send a 
TERMINAL RESPONSE with "Backward move in the proactive UICC session requested by the user" result 
value. 

If a flag of the command qualifier (see subclause 8.6) indicates that the ME shall wait for the user to clear 
message and if the ME decides that no user response has been received, the ME shall send a TERMINAL 
RESPONSE with "No response from user" result value. 

If the UICC includes a duration object, the ME shall limit the display time of the message for a period that does 
not exceed the requested duration. The timer starts when the text is displayed on the screen and stops when the 
TERMINAL RESPONSE is sent except if the text is to be sustained beyond an immediate response. The timeout 
may be used with other options of this command. The variable timeout does not affect TERMINAL RESPONSE 
values that are deriving from other chosen options of this command. 

- If the UICC includes an immediate response object, the ME shall immediately send TERMINAL RESPONSE 
(Command performed successfully). The ME shall continue to display the text until one of the following events 
occurs: 

a subsequent proactive command is received containing display data; 

the expiration of the variable display timeout, if so indicated by the duration object; 
the expiration of the short delay, if so indicated by the command qualifier; 
following a user MMI action; 
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when a higher priority event occurs, e.g. an incoming mobile terminated call. 

- No further TERMINAL RESPONSE shall be sent when the ME removes the text from the display, regardless of 
the cause. 

Otherwise, the ME shall send TERMINAL RESPONSE (Command performed successfully) at the expiration of 
either the short delay or the variable display timeout, or following a user MMI action not described above. 

In each case the availability of the screen for the subsequent information display is defined in subclause 6.9. 

NOTE 2: For the case where the text is cleared after a short delay, the ME may also allow the user to clear the 
display via the MMI prior to this. 

The ME shall reject normal priority text commands if the screen is currently being used for more than its normal stand- 
by display. If the command is rejected, the ME informs the UICC using TERMINAL RESPONSE (ME currently unable 
to process command - screen busy). 

High priority text shall be displayed on the screen immediately, except if there is a conflict of priority level of alerting 
such as incoming calls or a low battery warning. In that situation, the resolution is left to the ME. If the command is 
rejected in spite of the high priority, the ME shall inform the UICC using TERMINAL RESPONSE (ME currently 
unable to process command - screen is busy). 

If help information is requested by the user, this command may be used to display help information on the screen. The 
help information should be sent as high priority text and with the option that it should be cleared after a short delay. 

6.4.2 GET INKEY 

This command instructs the ME to display text and/or an icon (see subclause 6.5.4) and to expect the user to enter a 
single character. Any response entered by the user shall be passed transparently by the ME to the UICC. 

The text can be in one of three formats: 

- packed format in SMS default alphabet - (see subclause 8.15.2); 
unpacked format in SMS default alphabet - (see subclause 8.15.2); 
UCS2 alphabet format - (see subclause 8.15.3). 

The response can be from one of three character sets. This is specified by the UICC: 

- digits only (0-9, *, #, and +); 

characters from the SMS default alphabet; 

characters from the UCS2 alphabet. 

Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter a single character in 
response. 

If the user has indicated the need to go backwards in the proactive UICC session, the ME shall send a 
TERMINAL RESPONSE with "Backward move in the proactive UICC session requested by the user" result 
value. 

If the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with "Proactive UICC session terminated by the user" result value. 

If the ME decides that no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

If the UICC requests an immediate digit response, the ME shall only allow the user to enter a character that can 
be entered by a single key press (that means for MEs providing only the keypad as defined in 3G TS 22.030 [2], 
from the digits 0-9, * and # (but not +)). When the user has entered a digit, the ME shall pass the entered digit 
transparently to the UICC, using TERMINAL RESPONSE. The ME shall not display the entered digit in any 
way. The ME shall not allow the user to change the entered digit. The ME shall not request the user to confirm 
the response. 
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NOTE 1 : A larger portion of the screen may be used for display purposes, since the ME shall not display the 
entered digit in any way. 

If the UICC requests a digit only, the ME shall only allow the user to enter a character from the digits 0-9, *, # 
and +. When the user has entered a digit, the ME shall pass the entered digit transparently to the UICC, using 
TERMINAL RESPONSE. 

If help information is available for the command and if the user has indicated the need to get help information, 
the ME shall send a TERMINAL RESPONSE with "help information required by the user" result value. 
Depending of ME implementation, combination with the option "immediate response" and/or the option 
"variable timeout" may result that the user is unable to request the help. 

The ME support of help information combined with immediate response and/or timeout is indicated in the 
TERMINAL PROFILE. 

If the UICC requests a character from the SMS default alphabet, the ME shall allow the user to enter a character 
using characters from this alphabet. When the user has entered a character, the ME shall pass the entered 
character transparently to the UICC, using TERMINAL RESPONSE. 

- If the UICC requests a "Yes/No" response, the ME shall allow the user to enter either a positive or a negative 
decision using MMI means left to ME manufacturer's choice (keypad, touch screen, softkey,...). The ME may use 
SEND, ACCEPT or END functions in relation to GET INKEY "Yes/No" response. If used, the SEND and 
ACCEPT functions as defined in 3G 22.030 [2] shall mean positive decision and the END function as defined in 
3G 22.030 [2] shall mean a negative one. Depending on the user's choice, the ME shall pass the positive or a 
negative value to the UICC, using TERMINAL RESPONSE. 

- If the UICC requests a "Yes/No" response together with immediate digit response, the ME shall combine the 
behaviour of "Yes/No" UICC request with the behaviour of an immediate digit response UICC request. 

- If the UICC requests a variable timeout, the ME shall wait until either the user enters a single character or the 
timeout expires. The timer starts when the text is displayed on the screen and stops when the TERMINAL 
RESPONSE is sent. The ME shall pass the total display text duration (command execution duration) to the UICC 
using the TERMINAL RESPONSE. The time unit of the response is identical to the time unit of the requested 
variable timeout. The timeout may be used with other options of this command. The variable timeout does not 
affect TERMINAL RESPONSE values that are deriving from other chosen options of this command. ME support 
of this feature is indicated in the PROFILE DOWNLOAD. The behaviour of MEs that do not support this feature 
is dependent on the Comprehension Required flag. 

NOTE2: If the MMI of the ME requires more than one keypress in order to select a character, it is an 

implementation decision for the ME manufacturer how to indicate completion (e.g. timeout, pressing 
SEND, OK). It may be useful to echo the input character on the display. 

For digits only (0-9, *,# and +) and SMS default alphabet characters sets, the response shall be coded using the SMS 
default alphabet in unpacked format. 

6.4.3 GET INPUT 

This command instructs the ME to display text and/or an icon (see 6.5.4) and that any response string entered by the 
user shall be passed transparently by the ME to the UICC. If the UICC provides a default text, the ME shall display this 
default text, which the user may accept, reject or edit as the response string. 

The text can be in one of three formats: 

- packed format in SMS default alphabet (see subclause 8.15.2); 

unpacked format in SMS default alphabet (see subclause 8.15.2); 

UCS2 alphabet format (see subclause 8.15.3). 

The UICC indicates how many characters are expected for the response string, by giving a minimum and a maximum 
acceptable length. 

The UICC specifies the following variables for the response string it is expecting from the user: 

the response contains either digits only (0-9, *, # and +) or characters from one of the possible alphabets; 
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the response contains either characters coded in SMS default alphabet or characters coded in UCS2 alphabet; 

the response for digits only (0-9, *,# and +) or characters from SMS default alphabet is either in an unpacked 
format or in a packed format; 

the ME may display the text string being entered by the user (the response), or the ME shall hide the actual text 
string. 

The combination of characters from either the SMS default alphabet or the UCS2 alphabet and hidden entry mode is not 
allowed. In hidden entry mode, only digits from the set "0-9","*" and "#" are allowed for the user input. "+" is not 
allowed for user input in this mode. 

If the UICC requests that the user input (text string) is to be hidden, the ME shall prevent the text string from being 
identified by any means. For example, the text string shall not be displayed and no DTMF tones shall be emitted. 
Nevertheless, it is permissible for the ME to indicate the entry of characters, so long as the characters themselves are 
not revealed. 

Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter characters in 
response. 

The ME MMI is responsible for managing the entry of the correct number of characters. 

If the user has indicated the need to go backwards in the proactive UICC session, the ME shall send a 
TERMINAL RESPONSE with "Backward move in the proactive UICC session requested by the user" result 
value. 

If the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with "Proactive UICC session terminated by the user" result value. 

If the ME decides that no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

If the UICC requests digits only, the ME shall only allow the user to enter the digits 0-9, *, # and +. When the 
user has indicated completion, the ME shall pass the entered digit string transparently to the UICC, using 
TERMINAL RESPONSE. 

If the UICC requests characters from the UCS2 alphabet or SMS default alphabet, the ME shall allow the user to 
enter a character string using characters from one of these alphabets. When the user has indicated completion, 
the ME shall pass the entered text string transparently to the UICC, using TERMINAL RESPONSE. 

If help information is available for the command and if the user has indicated the need to get help information, 
the ME shall send a TERMINAL RESPONSE with 'help information required by the user' result value. 

If the UICC requests the user input to be in packed format, then the ME shall pack the text according to TS 23.038 [4] 
before submitting it to the UICC. 

6.4.4 MORE TIME 

This procedure is provided to allow the USAT task in the UICC more time for processing, where the processing is so 
long that it is in danger of affecting normal 3G operation, and clock stop prevents processing to take place in the 
background. 

The ME shall take no extraordinary action when it receives this command, and all other operations shall be unaffected. 
The ME shall conclude the command by sending TERMINAL RESPONSE (OK) to the UICC, as soon as possible after 
receiving the MORE TIME command. 

6.4.5 PLAY TONE 

This command instructs the ME to play an audio tone. 

Upon receiving this command, the ME shall check if it is currently in, or in the process of setting up (SET-UP message 
sent to the network, see 3G 24.008 [9]), a speech call. 
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If the ME is in, or is setting up a speech call, it shall superimpose the tone on top of the downlink audio (if any), 
for the duration given in the command. The progress or current state of the call shall not be affected in any way. 
The ME shall send the TERMINAL RESPONSE (Command performed successfully) as soon as possible after 
the tone has been completed and, if an alpha identifier was included and displayed, the screen is available for 
subsequent information display. 

If the ME is not in or setting up a speech call, it shall route the audio to the external ringer, or other appropriate 
audio device, and play the tone for the duration given in the command. The ME shall send the TERMINAL 
RESPONSE (Command performed successfully) as soon as possible after the tone has been completed and, if an 
alpha identifier was included and displayed, the screen is available for subsequent information display. 

If the user has indicated the need to end the proactive UICC application session while the ME plays the tone, the 
ME shall stop playing the tone and shall send a TERMINAL RESPONSE with "Proactive UICC application 
session terminated by the user" result value. 

If ME support for the specific tone requested is optional, and the ME does not support this particular tone, the 
ME shall inform the UICC using TERMINAL RESPONSE (Command beyond ME's capabiHties). 

This proactive command contains no information on how a call is progressing; therefore the ME shall not generate any 
verbal indication or display any text or graphical indication about the normal meaning of this tone (e.g. display "called 
subscriber busy"). If the UICC wishes to convey a meaning in text to the user, it shall do this through the alpha 
identifier data object and/or an icon (see subclause 6.5.4). 

The use of this alpha identifier by the ME is described below: 

If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user. 
If an icon is provided by the SIM, the icon indicated in the command may be used by the ME to inform the user, 
in addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4). 

If the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), the 
ME should not give any information to the user. 

If the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening 

If the ME is required to generate a supervisory tone due to the progress of the current call (e.g. the network sends the 
ME call control cause information) as defined in TS 22.001 [22], then the call supervisory tone shall take precedence 
over the tone requested by the UICC. 

6.4.6 POLL INTERVAL 

This procedure negotiates how often the ME shall send STATUS commands related to Proactive Polling (defined 
in3G TS 31.101 [13]). The UICC indicates the poll interval it requests from then onwards, and the ME responds 
through TERMINAL RESPONSE with the maximum interval that it will use. If the ME does not support the poll 
interval requested by the UICC, then the ME shall respond with the closest interval to the one requested by the UICC, 
or, if the intervals the ME can offer are equidistant (higher and lower) from the UICC's request, the ME shall respond 
with the lower interval of the two. 

Applications on the UICC should not request short time intervals for an extended period, as this will have an adverse 
effect on battery life, and should not use this command for time management purposes. 

6.4.7 REFRESH 

The purpose of this command is to enable the ME to be notified of the changes to the UICC configuration that have 
occurred as the result of a USIM application activity. It is up to the USIM application to ensure that this is done 
correctly. 

The UICC may indicate the AID of the USIM application it wants to REFRESH. 

- If the indicated USIM is active, the ME shall perform the REFRESH. 

- If indicated USIM is not active, the ME shall send a TERMINAL RESPONSE. The ME shall not select the 
indicated USIM. 
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If no AID is indicated, then the ME shall assume the REFRESH applies to the current USIM application. 

The command supports seven different modes: 

- USIM Initialization. This mode tells the ME to carry out USIM initialization as it is defined in TS 31.102 [14] 
only, starting after the PIN verification procedure. 

USIM File Change Notification. This mode advises the ME of the identity of the EFs that have been changed (in 
structure and/or contents) in the indicated USIM and files under DFtelecom- This information can be used by the 
ME if there is an image of USIM EFs in the ME's memory, to determine whether it needs to update this image. 

USIM Initialization and File Change Notification. This is a combination of the first two modes above. 

USIM Initialization and Full File Change Notification. This mode causes the ME to perform the USIM 
initialization procedure of the first mode above and advises the ME that several EFs have been changed (in 
structure or contents) in the indicated USIM. If there is an image of USIM EFs in the ME's memory, the ME 
shall completely update this image. 

UICC Reset. This mode causes the ME to run the UICC session termination procedure in accordance with 
TS 31.101 [13]. Subsequently, the ME performs a reset (warm reset preferred) on the UICC and starts a new 
application session. The ME shall not send the TERMINAL RESPONSE; this is an exception from the normal 
procedure, where TERMINAL RESPONSE is sent after completion of the command. The UICC shall interpret 
the reset as an implicit TERMINAL RESPONSE. The UICC Reset mode is used when a USAT requires ATR or 
complete UICC initialization procedures to be performed.- USIM Application Reset. This mode causes the ME 
to run the 3G session termination and the USIM application closure procedures in accordance with TS 31.102 
[14]. Subsequently, the ME performs USIM initialization procedure. 

3G Session Reset. This mode is equivalent to "USIM Initialization and File Change Notification" mode and in 
addition requires the ME to perform the MM Restart procedure defined in 3G 23.122 [7]. 

If the ME performs the REFRESH command successfully for only those EFs indicated in the mode, the ME shall 
inform the UICC using TERMINAL RESPONSE (OK), after it has completed its refreshing (i.e. taking into account the 
new value of the EFs). 

For REFRESH commands with mode other than "UICC Reset" or "USIM Application Reset", it is permissible for the 
ME, as part of its execution of the REFRESH command, to read EFs in addition to those notified by the UICC, or to 
perform a USIM initialisation, provided that the procedure executed wholly encompasses the mode requested by the 
UICC and does not involve re-entering the PIN. The ME shall not electrically reset the UICC. If the ME does the 
refreshing successfully, it shall inform the UICC using TERMINAL RESPONSE (Refresh performed with additional 
EFs read), after the ME has completed its refreshing. It should be noted that reading additional EFs will lengthen the 
refresh procedure. 

If the ME receives a REFRESH command while in a state where execution of the command would be unacceptable, 
upsetting the current user operation (e.g. notification during a call that the IMSI has changed), the ME shall inform the 
UICC using TERMINAL RESPONSE (ME currently unable to process command - currently busy on call) or 
TERMINAL RESPONSE (ME currently unable to process command - screen is busy) as appropriate. 

NOTE: Many MEs copy an image of the USIM application files to the ME at initialization to speed up access to 
these fields during a 3G session. One of the purposes of this coding of the REFRESH command is to 
enable MEs to change such an image efficiently. 

If, on receipt of the REFRESH command, the ME replies that it is busy (e.g. in call or navigating menus), the toolkit 
application may retry it later. 

It is recommended for the ME to minimise the use of sending temporary problem TERMINAL RESPONSE, as during 
the period between the UICC issuing a REFRESH command and the ME performing the refresh procedure, there may 
be inconsistencies between data held in the ME and in the UICC. However, responsibility for retrying of all pro-active 
commands lies with the UICC. 

6.4.7.1 EFiMsi changing procedure 

When an EFimsi is changed via Data Download or a USAT application and a REFRESH command is issued by the 
UICC the following rules apply to the UICC and ME: 
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USIM Initialization. This command shall not be used if an EFimsi is changed, as the behaviour of the UE is 
unpredictable; 

- File Change Notification. This command shall not be used if an EFimsi is changed, as the behaviour of the UE is 
unpredictable; 

USIM Initialization and File Change Notification. This command shall not be used if an EFjmsi is changed, as the 
behaviour of the UE is unpredictable; 

USIM Initialization and Full File Change Notification. This command shall not be used if an EFimsi is changed, 
as the behaviour of the UE is unpredictable; 

UICC Reset. Normal UICC Reset procedure is carried out; 

USIM Application Reset. Normal USIM Application Reset procedure is carried out; 

3G Session Reset. Normal 3G Session Reset procedure is carried out. 

If an EFimsi is to be updated, neither EFimsi nor EFloci shall be updated in the UICC before the 3G session termination 
procedure has been completed by the ME. 

6.4.8 SET UP MENU 

The UICC shall supply a set of menu items, which shall be integrated with the menu system (or other MMI facility) in 
order to give the user the opportunity to choose one of these menu items at his own discretion. Each item comprises a 
short identifier (used to indicate the selection), a text string and optionally an icon identifier, contained in an item icon 
identifier list data object located at the end of the list of items. 

The UICC shall include an alpha identifier, and optionally an icon identifier, which acts as a title for the list of menu 
items. This icon may be used by the ME to provide an entry into the list of toolkit menu items for the user. 

If an icon is provided by the UICC, the icon(s) indicated in the command may be used by the ME in addition to, or 
instead of the alpha identifier or text string, as indicated with the icon qualifier (see subclause 6.5.4). Additionally if soft 
key preferred is indicated in the command details and soft key for SET UP MENU is supported by the ME and the 
number of icons items does not exceed the number of soft keys available then the ME shall display those icons as soft 
key. 

The UICC may include an items next action indicator data object located at the end of the list of items. The inclusion of 
the items next action indicator is to allow the ME to indicate to the user the consequences of performing the selection of 
an item. 

NOTE: The maximum amount of data sent in one proactive UICC command is 256 bytes. It is therefore 

unavoidable that there is trade-off between the number of items and the length of the descriptive text (the 
alpha identifier of the SET-UP MENU command and the text strings of the items), e.g. for an average 
length of 10 bytes per text string the maximum amount of items is 18. 

The list of menu items shall then be part of the menu system of the ME and the user is allowed to select an item from 
this list. The presentation style is left as an implementation decision to the ME manufacturer. However, the ME shall 
present the menu items in the order given by the UICC, unless instructed otherwise by the user, or when this would be 
inappropriate for the presentation style of the ME. The menu provided by the UICC in the last SET UP MENU 
command shall no longer be part of the menu system of the ME if the ME is powered off or the UICC is removed or 
electrically reset. 

Any subsequent SET-UP MENU command replaces the current list of menu items supplied in the previous SET-UP 
MENU command. The SET-UP MENU command can also be used to remove a menu from the menu system in the ME; 
see subclause 6.6.7. 

When the ME has successfully integrated or removed the list of menu items, it shall send TERMINAL RESPONSE 
(OK) to the UICC. 

When the ME is not able to successfully integrate or remove the list of menu items, it shall sent TERMINAL 
RESPONSE (Command beyond ME's capabiUties). 

When the user has selected one of the menu items of this menu item list, then the ME shall use the Menu Selection 
mechanism to transfer the identifier of the selected menu item to the UICC. 
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If help is available for the command and if the user has indicated the need to get help information on one of the menu 
items, the ME shall use the Menu Selection mechanism to inform the UICC about this help request. 

6.4.9 SELECT ITEM 

The UICC shall supply a set of items from which the user may choose one. Each item comprises a short identifier (used 
to indicate the selection), a text string and optionally an icon identifier, contained in an item icon identifier list data 
object located at the end of the list of items. 

Optionally the UICC may include an alpha identifier, and an icon identifier. These are intended to act as a title for the 
list of items. The UICC may include an items next action indicator data object located at the end of the list of items. The 
inclusion of the items next action indicator is to allow the ME to indicate to the user the consequences of performing the 
selection of an item. 

The alpha identifier included by the UICC shall be used by the ME as the title for the list of items. 

If an icon is provided by the UICC, the icon(s) indicated in the command may be used by the ME in addition to, or 
instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4). Additionally, if "selection using 
soft key preferred" is indicated in the command details and "soft key for SELECT ITEM" is supported by the ME and 
the number of icons items does not exceed the number of soft keys available, then the ME shall display those icons as 
soft keys. 

NOTE: The maximum amount of data sent in one proactive UICC command is 256 bytes. It is therefore 

unavoidable that there is trade-off between the number of items and the length of the descriptive text (the 
alpha identifier of the SELECT ITEM command and the text strings of the items), e.g. for an average 
length of 10 bytes per text string the maximum amount of items is 18. 

The ME shall present the list of text strings to the user, and allow the user to select an item from this list. A flag of the 
command qualifier (see subclause 8.6) indicates whether the list is a choice of navigation options, or a choice of data 
values. The presentation style is left as an implementation decision to the ME manufacturer. However, the ME shall 
present the menu items in the order given by the UICC, unless instructed otherwise by the user, or when this would be 
inappropriate for the presentation style of the ME. The menu provided by the UICC in the last SET UP MENU 
command shall no longer be part of the menu system of the ME if the ME is powered off or the UICC is removed or 
electrically reset. 

The UICC may supply with the list, if applicable, indication of the default item, e.g. the previously selected item. 

When the user has selected an item, the ME shall send TERMINAL RESPONSE (OK) to the UICC with the identifier 
of the item chosen. 

If the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with "Proactive UICC session terminated by the user" result value. 

If the user has indicated the need to go backwards in the proactive UICC session, the ME shall send a 
TERMINAL RESPONSE with "Backward move in the proactive UICC session requested by the user" result 
value. 

If the ME decides that no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

If help information is available for the command and if the user has indicated the need to get help information, 
the ME shall send a TERMINAL RESPONSE with "help information required by the user" result value to the 
UICC with the identifier of the item for which the user is requiring help information. 

6.4.1 SEND SHORT MESSAGE 

Two types are defined: 

a short message to be sent to the network in an SMS-SUBMIT message, or an SMS-COMMAND message, 
where the user data can be passed transparently; 

a short message to be sent to the network in an SMS-SUBMIT message where the text needs to be packed by the 
ME. 
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Where the text has been packed, the text string provided by the UICC shall not be longer than 160 characters. It shall 
use the SMS default 7-bit coded alphabet, packed into 8-bit octets, in accordance with TS 23.038 [4]. The data coding 
indication contained in the Data Coding Scheme byte shall be "default alphabet". The text length (which is part of the 
SMS TPDU) given by the UICC shall state the number of 7-bit characters in the text string. The command details shall 
indicate "packing not required". 

8-bit data Short Messages may be sent by the UICC. The command shall indicate packing not required. The data coding 
indication contained in the Data Coding Scheme byte shall be "8 bit". The string shall not be longer than 140 bytes, and 
the length (in SMS TPDU) shall state the number of bytes in the string. 

If UCS2 is supported by the ME, 16-bit data Short Messages may be sent by the UICC. The text string provided by the 
UICC shall not be longer than 70 characters. It shall use the 16-bit UCS2 alphabet format, in accordance with 
TS 23.038 [4]. The text length (which is part of the SMS TPDU) given by the UICC shall state the number of 16-bit 
characters in the text string. The command details shall indicate "packing not required". 

SMS commands may be sent by the UICC. These shall count as packed text message. The SMS TPDU from the UICC 
shall indicate SMS-COMMAND. The command details shall indicate "packing not required". 

Where packing by the ME is required, the text string provided by the UICC shall not be longer than 160 characters. It 
shall use the SMS default 7-bit coded alphabet as defined in TS 23.038 [4] with bit 8 set to 0. The text length given by 
the UICC shall state the number of characters in the text string. The ME shall pack the text string and modify the Data 
Coding Scheme byte to "default alphabet" in accordance with TS 23.038 [4] before submitting the message to the 
network. 

Optionally, the UICC may include in this command an alpha identifier. The use of this alpha identifier by the ME is 
described below. 

If the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that the 
ME is sending a short message. If an icon is provided by the UICC, the icon indicated in the command may be 
used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon 
qualifier (see subclause 6.5.4). 

If the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), this 
is an indication that the ME should not give any information to the user on the fact that the ME is sending a short 
message. 

If the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what is 
happening. 

If the ME is capable of SMS-MO, then it shall send the data as a Short Message TPDU to the destination address. The 
ME shall give the result to the UICC using TERMINAL RESPONSE (indicating successful or unsuccessful 
transmission of the Short Message) after receiving an SMS RP-ACK or RP -Error from the network. If an alpha 
identifier was provided by the UICC, the ME should not give any information to the user at the reception of SMS RP- 
ACK or RP-Error. 

If the Short Message TPDU is unsuccessfully received by the network (e.g. the reception of a CP-ERROR), the ME 
shall inform the UICC using TERMINAL RESPONSE (network currently unable to process command). If a null alpha 
identifier was provided by the UICC, the ME should not give any information to the user at the unsuccessful network 
reception. 

The destination address and the SMSC address included in the SEND SHORT MESSAGE proactive command shall not 
be checked against those of the FDN list, even if the Fixed Dialling Number service is enabled. 

6.4.11 SENDSS 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

if the command is rejected because the ME is busy on an SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

if the command is rejected because the ME is busy on a USSD transaction, the ME shall inform the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on USSD transaction); 
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if the command is rejected because the ME does not support that Supplementary Service, the ME informs the 
UICC using TERMINAL RESPONSE (Command beyond ME's capabiHties). 

If the ME is able to send the SS request, the ME shall: 

send the SS request immediately, without need to alert the user first; 

optionally, the UICC may include in this command an alpha-identifier. The use of this alpha-identifier by the 
ME is described below: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
the ME is sending a SS request. If an icon is provided by the UICC, the icon indicated in the command may 
be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the 
icon qualifier (see subclause 6.5.4); 

if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), 
this is an indication that the ME should not give any information to the user on the fact that the ME is 
sending an SS request; 

if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what 
is happening. 

once an SS Return Result message not containing an error has been received from the network, the ME shall 
inform the UICC that the command has been successfully executed, using TERMINAL RESPONSE. This 
command shall include the contents of SS Return Result as additional data. 

If a null alpha identifier was provided by the UICC, the ME should not give any information to the user at the 
reception of an SS Return Result message; 

if the command is rejected because the network cannot support or is not allowing the Supplementary Service 
request, the ME informs the UICC using TERMINAL RESPONSE (SS Return Result error code). 
If a null alpha identifier was provided by the UICC, the ME should not give any information to the user at the 
reception of a SS Return Result message; 

if the SS request is unsuccessfully received by the network, the ME shall inform the UICC using TERMINAL 
RESPONSE (network currently unable to process command), and not retry to send the request. 
If a null alpha identifier was provided by the UICC, the ME should not give any information to the user at the 
reception of a SS Return Result message. 

If the ME supports the Last Number Dialled service, the ME shall not store in EFl^d the supplementary service control 
string sent by the UICC in this command. 

The supplementary service control string included in the SEND SS proactive command shall not be checked against 
those of the FDN list, even if the Fixed Dialling Number service is enabled. 

6.4.12 SENDUSSD 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

if the command is rejected because the ME is busy on a USSD transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on USSD transaction); 

if the command is rejected because the ME is busy on a SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction). 

If the ME is able to send the USSD request, the ME shall: 

send the USSD immediately, without need to alert the user first; 

optionally, the UICC may include in this command an alpha-identifier. The use of this alpha-identifier by the 
ME is described below: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
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the ME is sending a USSD request. If an icon is provided by the UICC, the icon indicated in the command 
may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with 
the icon qualifier (see subclause 6.5.4); 

if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), 
this is an indication that the ME should not give any information to the user on the fact that the ME is 
sending a USSD request; 

if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what 
is happening. 

once the USSD transaction is initiated, a dialogue between the network and the user may occur which involves 
the MMI of the ME. If an alpha identifier was initially provided by the UICC, this alpha identifier may be 
discarded during this dialogue; 

once a RELEASE COMPLETE message containing the USSD Return Result message not containing an error 
has been received from the network, the ME shall inform the UICC that the command has been successfully 
executed, using TERMINAL RESPONSE. This command shall include the text contained in the USSD Return 
Result in a Text String data object. If a null alpha identifier was provided by the UICC, the ME should not give 
any information to the user at the reception of a USSD Return Result message; 

if the UE clears the transaction by sending a RELEASE COMPLETE upon request of the user, the ME shall 
inform the UICC using TERMINAL RESPONSE (USSD transaction terminated by user); 

if the USSD operation is rejected because the network cannot support or is not allowing mobile initiated USSD, 
the ME informs the UICC using TERMINAL RESPONSE (USSD Return Result error code). If a null alpha 
identifier was provided by the UICC, the ME should not give any information to the user at the reception of a 
USSD Return Result message; 

if the USSD request is unsuccessfully received by the network, the ME shall inform the UICC using 
TERMINAL RESPONSE (network currently unable to process command), and not retry to send the request. If a 
null alpha identifier was provided by the UICC, the ME should not give any information to the user at the 
reception of a USSD Return Result message. 

6.4.13 SET UP CALL 

Three types are defined: 

set up a call, but only if not currently busy on another call; 

set up a call, putting all other calls (if any) on hold; 

set up a call, disconnecting all other calls (if any) first. 

For each of these types, the UICC may request the use of an automatic redial mechanism according to GSM 02.07 [20]. 
The UICC may also request an optional maximum duration for the redial mechanism. The ME shall attempt at least one 
call set-up. 

In addition to the called party number, the command may contain capability configuration parameters (giving the bearer 
capability to request for the call) and the called party subaddress. The ME shall use these in its call set-up request to the 
network. The command may also include DTMF digits, which the ME shall send to the network after the call has 
connected. The ME shall not locally generate audible DTMF tones and play them to the user. 

NOTE: On the downlink audio, DTMF tones reflected by the network may be heard. 

It is possible for the UICC to request the ME to set up an emergency call by supplying the number "112" as called party 
number. If the UICC supplies a number stored in EFgcc^ this shall not result in an emergency call. 

The number included in the SET UP CALL proactive command shall not be checked against those of the FDN list, even 
if the Fixed Dialling Number service is enabled. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 
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if the command is rejected because the ME is busy on another call, the ME informs the UICC using TERMINAL 
RESPONSE (ME unable to process command - currently busy on call); 

if the command is rejected because the ME is busy on a SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

if the command is rejected because the ME cannot support Call Hold, or because the ME does not support the 
capability configuration parameters requested by the UICC, the ME informs the UICC using TERMINAL 
RESPONSE (Command beyond ME's capabilities); 

if the command is rejected because the network cannot support or is not allowing Call Hold of a multi party call, 
the ME informs the UICC using TERMINAL RESPONSE (SS Return Result error code); 

if the command is rejected because the network cannot support or is not allowing Call Hold of a single call, the 
ME informs the UICC using TERMINAL RESPONSE (Network currently unable to process command). 

If the ME is able to set up the call on the serving network, the ME shall: 

alert the user (as for an incoming call). This is the confirmation phase; 

optionally, the UICC may include in this command one or two alpha-identifiers. The use of these alpha- 
identifiers by the ME is described below: 

if the first alpha identifier is provided by the UICC and is not a null data object, the ME shall use it during the 
user confirmation phase. This is also an indication that the ME should not give any other information to the 
user during the user confirmation phase. If an icon is provided by the UICC, the icon indicated in the 
command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as 
indicated with the icon qualifier (see subclause 6.5.4); 

if the first alpha identifier is not provided by the UICC or is a null data object (i.e. length = '00' and no value 
part), the ME may give information to the user; 

if the second alpha identifier (i.e the one after the mandatory address object) is provided by the UICC and is 
not a null data object, the ME shall use it during the call set-up phase and during the call. If an icon is 
provided by the UICC, the icon indicated in the command may be used by the ME to inform the user, in 
addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4); 

if the second alpha identifier is not provided by the UICC or is a null data object (i.e. length = '00' and no 
value part), the ME may give information to the user. 

if the user accepts the call, the ME shall then set up a call to the destination address given in the response data, 
with the relevant capability configuration parameters and called party subaddress (if provided by the UICC); 

if the user does not accept the call, or rejects the call, then the ME informs the UICC using TERMINAL 
RESPONSE (user did not accept the proactive command). The operation is aborted; 

if the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with "Proactive UICC session terminated by the user" result value. 

optionally, during call set-up, the ME can give some audible or display indication concerning what is happening; 

once a CONNECT message has been received from the network (defined in 3G 24.008), the ME shall inform the 
UICC that the command has been successfully executed, using TERMINAL RESPONSE. Operation of the call 
then proceeds as normal. 

If the first call set-up attempt is unsuccessful: 

- if the UICC did not request redial then the ME shall inform the UICC using TERMINAL RESPONSE (network 
currently unable to process command), and not redial to set-up the call; 

if the UICC requested redial, then the ME may automatically redial the call (depending on its 
capability/configuration). In this case, the ME shall not send a command result to the UICC concerning the first 
or any subsequent failed set-up attempts. If the call set-up has not been successful, and the ME is not going to 
perform any more redials, or the time elapsed since the first call set-up attempt has exceeded the duration 
requested by the UICC, then the ME shall inform the UICC using TERMINAL RESPONSE (network currently 
unable to process command), and the redial mechanism shall be terminated; 
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if the user stops the call set-up attempt or the redial mechanism before a result is received from the network, the 
ME informs the UICC using TERMINAL RESPONSE (user cleared down call before connection or network 
release). 

If the ME supports the Last Number Dialled service, the ME shall not store in EFlnd the call set-up details (called party 
number and associated parameters) sent by the UICC in this command. 

6.4.14 POLLING OFF 

This command disables the Proactive Polling (defined in 3G TS 3L101 [13]). UICC Presence Detection (defined in 
3G TS 31.101 [13]) is not affected by this command. 

6.4.15 PROVIDE LOCAL INFORMATION 

This command requests the ME to send current local information to the UICC. At present, this information is restricted 
to: 

location information: the mobile country code (MCC), mobile network code (MNC), location area code (LAC) 
and cell ID of the current serving cell; 

- thelMEIoftheME; 

the Network Measurement Results and the BCCH channel list, suitable only for GSM access network; 

the current date, time and time zone; 

the current ME language setting; 

the Timing Advance, suitable only for GSM access network; 

the current access technology. 

The ME shall return the requested local information within a TERMINAL RESPONSE. Where location information or 
Network Measurement Results has been requested and no service is currently available, then the ME shall return 
TERMINAL RESPONSE (ME currently unable to process command - no service). Where location information or 
Network Measurement Results has been requested and the ME is on limited service (e.g. emergency calls only), the ME 
shall return the data requested in the TERMINAL RESPONSE with the general result (Limited Service). 

NMR are only available if the ME is connected to a GSM access network. If the NMR are requested and a call is in 
progress, the value of all the returned parameters provided by the ME in the response to the command will be valid. The 
NMR returned when a call is in progress from MEs supporting multiband operation, shall be according to the value of 
the multiband reporting parameter as defined in TS 44.018 [28]. If a call is not in progress (i.e. ME is in idle mode) 
some of the returned parameters (e.g. RXQUAL) may be invalid. In idle mode, MEs supporting multiband operation 
shall ignore the value of the multiband reporting parameter and the NMR returned shall be as defined in TS 44.018 [28] 
when the multiband reporting parameter equals zero. 

NOTE 2: When in idle mode, the only information element on which it is possible to rely on is the RXLEV-FULL- 
SERVING-CELL, which contains the value of the received signal strength on the BCCH of the current 
serving cell. 

NOTE 3: Network Measurement Results are defined in TS 44.018 [28] as Measurement Results. 

The BCCH channel list is only available if the ME is connected to a GSM access network. 

The ME shall return the current date and time as set by the user. If available, the ME shall also return the time zone 
known from the network with the NITZ feature (see 3G 22.042 [3]). If the time zone information is not available, the 
ME shall return 'FF' for this element. 

If language setting is requested, the ME shall return the currently used language. 

Timing advance is only available if the ME is connected to a GSM access network. If the Timing Advance is requested, 
the ME shall return the timing advance value that was received from the BTS during the last active dedicated 
connection (e.g. for call or SMS). Timing advance is defined in TS 44.018 [28]. An ME supporting the Timing Advance 
feature shall be able to store the last value of timing advance. In addition to the timing advance value, the ME shall 
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return its current status (i.e. ME is in idle mode or not) in order for the application to be aware of potential 
misinterpretation of the timing advance value. Caution should be taken if using the Timing Advance value for distance 
measurement as reflections from the external environment (buildings etc.) may affect the accuracy. 

If the access technology is requested, the ME shall return the current access technology that the ME is using. 

6.4.16 SET UP EVENT LIST 

The UICC shall use this command to supply a set of events. This set of events shall become the current list of events for 
which the ME is to monitor. 

Any subsequent SET UP EVENT LIST command replaces the current list of events supplied in the previous SET UP 
EVENT LIST command. The SET UP EVENT LIST command can also be used to remove the entire list of events 
current in the ME; see subclause 6.6. 16. The list of events provided by the UICC in the last SET UP EVENT LIST 
command shall be removed if the ME is powered off or the UICC is removed or electrically reset. 

When the ME has successfully accepted or removed the list of events, it shall send TERMINAL RESPONSE (OK) to 
the UICC. 

When the ME is not able to successfully accept or remove the list of events, it shall send TERMINAL RESPONSE 
(Command beyond ME's capabilities). 

When one of the events in the current list occurs, then the ME shall use the Event Download mechanism to transfer 
details of the event to the UICC; see subclause 7.5. 

6.4.1 7 PERFORM CARD APDU 

This subclause applies only if class "a" is supported. 

This command requests the ME to send an APDU command to the additional card (Card x). 

The command includes: 

the additional card reader identifier, which is part of the Device Identities object; 

the APDU command to be performed. 

Upon receiving this command, the ME shall decide if it is able to execute the command: 

if the command is rejected because the card reader identity is not valid, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - Card reader not valid); 

if the command is rejected because the card reader is not present or has been removed, the ME informs the UICC 
using TERMINAL RESPONSE (MultipleCard command error - Card reader removed or not present); 

if the command is rejected because the card is not present or has been removed, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - Card removed or not present); 

if the command is rejected because the card reader is busy, the ME informs the UICC using TERMINAL 
RESPONSE (MultipleCard command error - Card reader busy); 

if the command is rejected because the card is not powered on, the ME informs the UICC using TERMINAL 
RESPONSE (MultipleCard command error - Card powered off); 

if the command is rejected because the received C-APDU format is not valid, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - C-APDU format error). 

If the ME is able to transfer the C-APDU to the addressed card, the ME shall: 

transfer the C-APDU to the addressed card, through the selected ME- Card x protocol; 

extract the R-APDU data from the addressed card if so requested by the UICC; 

if the command fails because no response is received from Card x, the ME informs the UICC using TERMINAL 
RESPONSE (MultipleCard command error - Card mute); 
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if the command fails because of any form of transmission error, the ME informs the UICC using TERMINAL 
RESPONSE (MultipleCard command error - Transmission error); 

if the command fails because the ME does not support the protocol used by Card x, the ME informs the UICC 
using TERMINAL RESPONSE (MultipleCard command error - Protocol not supported). 

If the command is performed successfully from a protocol point of view, the ME shall include the R-APDU within the 
TERMINAL RESPONSE command. 

6.4.18 POWER OFF CARD 

This subclause applies only if class "a" is supported. 

This command requests the ME to close a session with the additional card (Card x). 

The command includes the additional card reader identifier, which is part of the Device Identities object. 

Upon receiving this command, the ME shall decide if it is able to execute the command: 

if the command is rejected because the card reader identity is not valid, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - Card reader not vahd); 

if the command is rejected because the card reader is not present or has been removed, the ME informs the 
UICC using TERMINAL RESPONSE (MultipleCard command error - Card reader removed or not present); 

if the command is rejected because the card is not present or has been removed, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - Card removed or not present); 

if the command is rejected because the card reader is busy, the ME informs the UICC using TERMINAL 
RESPONSE (MultipleCard command error - Card reader busy). 

If the ME is able to execute the command, the addressed Card x shall be deactivated according to ISO/IEC 7816-3 [16]. 

6.4.19 POWER ON CARD 

This subclause applies only if class "a" is supported. 

This command requests the ME to start a session with the additional card (Card x). 

The command includes the additional card reader identifier, which is part of the Device Identities object. 

Upon receiving this command, the ME shall decide if it is able to execute the command: 

if the command is rejected because the card reader identity is not valid, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - Card reader not valid); 

if the command is rejected because the card reader is not present or has been removed, the ME informs the 
UICC using TERMINAL RESPONSE (MultipleCard command error - Card reader removed or not present); 

if the command is rejected because the card is not present or has been removed, the ME informs the UICC using 
TERMINAL RESPONSE (MultipleCard command error - Card removed or not present); 

if the command is rejected because the card reader is busy, the ME informs the UICC using TERMINAL 
RESPONSE (MultipleCard command error - Card reader busy). 

If the ME is able to execute the command, and the addressed Card x is powered off, the ME shall activate the addressed 
Card X according to ISO/IEC 7816-3 [16]. If the addressed Card x is already powered on, the ME shall treat the 
POWER ON CARD command as a warm reset, as defined in ISO/IEC 7816-3 [16]. 

The ME shall return the Answer To Reset within the TERMINAL RESPONSE command. If no ATR is received, the 
ME shall inform the UICC using TERMINAL RESPONSE (MultipleCard command error - Card mute). 

Application writers are advised that the Card x should not be powered up for longer than necessary due to battery life 
considerations. 
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6.4.20 GET READER STATUS 

This subclause applies only if class"a" is supported. 

This command requests the ME to get information about all interfaces or the indicated interface to additional card 
reader(s). This information is restricted to: 

card reader status; 

card reader identifier. 

The ME shall return the requested information from the interfaces to additional card reader(s) within a TERMINAL 
RESPONSE command. 

6.4.21 TIMER MANAGEMENT 

This command requests the ME to manage timers running physically in the ME. The possible actions on timers are 
defined below: 

start a timer; 

deactivate a timer; 

get the current value of a timer. 

The UICC and the ME are able to manage 8 different timers running in parallel. The possible duration of a timer is 
between 1 second and 24 hours. The resolution of a timer is 1 second. The precision of the returned value can not be 
relied upon in all cases due to potential ME activities. When the ME is switched off or the UICC is reset, all timers are 
deactivated in the ME. 

For a given timer: 

when the UICC requests the ME to start the timer with a duration, then: 

the ME shall start the timer with the duration given by the UICC, even if this timer is already running. When 
a timer is started, it takes the value given by the UICC, and is then decremented. The ME shall inform the 
UICC that the command has been successfully executed, using TERMINAL RESPONSE (OK). 

when the UICC requests the ME to deactivate the timer, then: 

- if the timer is running, the ME shall deactivate the timer. This prevents the UICC from receiving unnecessary 
information at the expiration of a timer. The ME shall pass the current value of the timer (i.e. the duration 
that remains before the timer elapses) to the UICC, using TERMINAL RESPONSE; 

- if the timer is already deactivated, the ME shall inform the UICC using TERMINAL RESPONSE ('action in 
contradiction with the current timer state'). 

when the UICC requests the ME to get the current value of the timer, then: 

if the timer is running, the ME shall pass the current value of the timer (i.e. the duration that remains before 
the timer elapses) to the UICC, using TERMINAL RESPONSE; 

- if the timer is deactivated, the ME shall inform the UICC using TERMINAL RESPONSE ('action in 
contradiction with the current timer state'). 

When a timer expires (i.e. reaches zero), the ME shall use the Timer Expiration mechanism to transfer the identifier of 
the timer that has expired and the difference between the time when this transfer occurs and the time when the timer 
was initially started. The ME shall then deactivate the timer. 

6.4.22 SET UP IDLE MODE TEXT 

The UICC shall supply a text string, which shall be displayed by the ME as an idle mode text if the ME is able to do it. 
The presentation style is left as an implementation decision to the ME manufacturer. The idle mode text shall be 
displayed in a manner that ensures that neither the network name nor the service providers name are affected. 
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If idle mode text is competing with other information to be displayed on the same area, for instance a CB message, the 
idle mode text shall be replaced by the other information. It is up to the ME to restore the idle mode text when the other 
information has no longer to be displayed. 

The text shall be removed from the ME's memory and display if either: 

the ME is powered off; or 

the UICC is removed or electrically reset; or 

a REFRESH command occurs with "initialisation" or "reset". 

Any subsequent SET UP IDLE MODE TEXT command replaces the current idle mode text of the previous SET UP 
IDLE MODE TEXT. The SET UP IDLE MODE TEXT command can also be used to remove an idle mode text from 
the ME; see subclause 6.6.22. 

When the ME has successfully integrated or removed an idle mode text, it shall send TERMINAL RESPONSE (OK) to 
the UICC. 

When the ME is not able to successfully integrate or remove the idle mode text, it shall send TERMINAL RESPONSE 
"Command beyond ME's capabilities" to the UICC. 

6.4.23 RUN AT COMMAND 

This subclause applies only if class "b" is supported by the ME and enabled by the subscriber through the ME. 

The UICC uses this command to send an AT Command to the ME as though initiated by an attached TE. The ME shall 
then return an AT Response within a TERMINAL RESPONSE to the UICC. 

If this feature is enabled, the UICC uses this command to send an AT Command to the ME as though initiated by an 
attached TE. The ME shall then return an AT Response within a TERMINAL RESPONSE to the UICC. 

If this feature is disabled or the mobile does not support the RUN AT COMMAND, then if the US AT receives an 
instruction from the network to issue the command, the USAT should return an error indication in accordance with the 
AT Response set (e.g. as indicated in 3G 27.007 [12]) to the network. 

Optionally, the UICC may include in this command an alpha identifier. The use of this alpha identifier by the ME is 
described below: 

if the alpha identifer is provided by the UICC and is not a null data object, the ME shall use it to inform the user. 
This is also an indication that the ME should not give any other information to the user on the fact that the ME is 
performing an AT command. If an icon is provided by the UICC, the icon indicated in the command may be 
used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon 
qualifier (see subclause 6.5.4); 

if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), this 
is an indication that the ME should not give any information to the user on the fact that the ME is performing an 
AT command; 

if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what is 
happening. 

6.4.24 SEND DTMF 

This command requests the ME to send a DTMF string after a call has been successfully established either by the 
proactive command SET UP CALL or the user. This command is independant of sending DTMF within the call set up 
(as defined in the SET UP CALL command) and therefore, can be used at any time during a call. 

The ME shall not locally generate audible DTMF tones and play them to the user. 

NOTE: On the downlink audio, DTMF tones reflected by the network may be heard. 

It shall be possible for the user to deactivate this command. 

The sending of a DTMF string applies only to the currently active call. 
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The TERMINAL RESPONSE indicating that the command has been performed successfully shall be sent after the 
complete DTMF string has been sent to the network by the ME. 

If the command is sent in idle mode, or a call is terminated or put on hold before the complete DTMF string has been 
sent to the network, the ME shall inform the UICC using TERMINAL RESPONSE '20' with the additional information 
"Not in speech call". 

If the user indicates the need to end the proactive UICC application session whilst the ME is sending the DTMF string, 
the ME shall stop sending the DTMF string and shall send a TERMINAL RESPONSE with "Proactive UICC 
application session terminated by the user" result value. 

Optionally, the UICC may include in this command an alpha identifier. The use of this alpha identifier by the ME is 
described below: 

if the alpha identifer is provided by the UICC and is not a null data object, the ME shall use it to inform the user. 
This is also an indication that the ME should not give any other information to the user on the fact that the ME is 
performing a SEND DTMF command. If an icon is provided by the UICC, the icon indicated in the command 
may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the 
icon qualifier (see subclause 6.5.4); 

if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), this 
is an indication that the ME should not give any information to the user on the fact that the ME is performing a 
SEND DTMF command. 

If the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what is 
happening. 

6.4.25 LANGUAGE NOTIFICATION 

The UICC shall use this command to notify the ME about the language currently used for any text string within 
proactive commands or envelope command responses. 

The notified language stays valid within the ME until the end of the card session or upon executing another 
LANGUAGE NOTIFICATION command. 

When the USAT application is not aware of the current US AT application language, no specific language is in use or 
several languages are in use, the UICC may notify non-specific language. This has the effect of cancelling a previous 
specific LANGUAGE NOTIFICATION. 

Two types of language notification are defined: 

specific, where an additional Language object shall be included by the UICC; 

non-specific, where no Language object shall be included by the UICC. 

Regardless of whether the ME recognises the notified language or not, the ME shall send TERMINAL RESPONSE 
(OK) to the UICC. 

The ME may use the language included in LANGUAGE NOTIFICATION as appropriate. For instance, this could be 
done to avoid a mix of languages in screen displays combining ME MMI and USAT originating text strings. 

6.4.26 LAUNCH BROWSER 

This command is used to request a browser inside a browser-enabled ME to interpret the content corresponding to a 
URL. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

if the command is rejected because the browser on the ME is busy or not available, the ME informs the UICC 
using TERMINAL RESPONSE (ME unable to process command - browser unavailable; 

if the command is rejected because the ME is busy on a SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - ME currently unable to process command); 
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if the command is rejected because the bearer provided in the command is not available, the ME informs the 
UICC using TERMINAL RESPONSE (ME unable to process command - bearer unavailable). 

If the ME is able to execute the command: 

the ME shall inform the UICC that the command has been successfully taken into account, using TERMINAL 
RESPONSE; 

the UICC shall end the proactive session; 

then the ME shall request content using the URL. 

If the gateway addresses and/or the bearer objects are present in the command and are non null data objects, then the 
browser shall use these data to request content using the URL. If the gateway addresses, bearer objects. Provisioning 
File Reference, Browser Identity or URL are null objects or missing, then the ME shall use default values (for an 
example, see Annex J reference [2]). 

The ME shall ask the user for confirmation using the Alpha Identifier/Icon Identifier (user confirmation phase) if 
present, when it receives a LAUNCH BROWSER command which requests the existing browser session connected to a 
new URL or to terminate a browser session. 

The way the ME requests content using the URL is outside the scope of the present document (for an example, see 
annex J reference [1]). 

NOTE: That there is a maximum size for the URL that can be given in argument of this proactive command. 

6.4.27 OPEN CHANNEL 

6.4.27.1 OPEN CHANNEL related to CS bearer 

This subclause applies only if class "e" is supported. 

Upon receiving this command, the ME shall decide if it is able to execute the command. The UICC shall indicate 
whether the ME should establish the link immediately or upon receiving the first transmitted data (on demand). 

The UICC provides to the ME a list of parameters necessary to establish a link. 

The UICC may request the use of an automatic reconnection mechanism according to GSM 02.07 [20]. The UICC may 
also request an optional maximum duration for the reconnection mechanism. The ME shall attempt at least one link 
establishment set-up. 

The UICC may also request an optional maximum duration for the ME to automatically release the link if no data is 
exchanged. 

If the Fixed Dialling Number service is enabled, the address included in the OPEN CHANNEL proactive command 
shall not be checked against those of the FDN list. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

if immediate link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the UICC, the ME sets up the channel using the best parameters it can support and informs the 
UICC of the channel identifier and the modified parameters using TERMINAL RESPONSE (Command 
performed with modification); 

if immediate link establishment is requested and the ME is unable to set-up the link with the network using the 
exact parameters provided by the UICC, the ME informs the UICC using TERMINAL RESPONSE (Network 
currently unable to process command). The operation is aborted; 

if on demand link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the UICC, the ME sets up the channel using the best parameters it can support and informs the 
UICC of the channel identifier and the modified parameters using TERMINAL RESPONSE (Command 
performed with modification); 
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if the command is rejected because the ME has no channel left with the requested bearer capabilities, the ME 
informs the UICC using TERMINAL RESPONSE (Bearer independent protocol error). The operation is aborted; 

- if the user does not accept the channel set-up, the ME informs the UICC using TERMINAL RESPONSE (User 
did not accept the proactive command). The operation is aborted; 

if the user has indicated the need to end the proactive UICC session, the ME informs the UICC using 
TERMINAL RESPONSE(Proactive UICC session terminated by the user). The operation is aborted; 

if the command is rejected because the ME is busy on another call, the ME informs the UICC using TERMINAL 
RESPONSE (ME unable to process command - currently busy on call). The operation is aborted; 

if the command is rejected because the ME is busy on a SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction). The operation is 
aborted. 

The ME shall inform the UICC that the command has been successfully executed using TERMINAL RESPONSE: 

if immediate link establishment is requested, the ME allocates buffers, sets up the link and informs the UICC and 
reports the channel identifier using TERMINAL RESPONSE (Command performed successfully); 

if on demand link establishment is requested, the ME allocates buffers, informs the UICC and reports the 
channel identifier using TERMINAL RESPONSE (Command performed successfully). 

If the ME is able to set up the channel on the serving network, the ME shall: 

alert the user (as for an incoming call). This is the confirmation phase; 

optionally, the UICC may include in this command an alpha-identifier. The use of this alpha-identifier by the 
ME is described below: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it during the 
user confirmation phase. This is also an indication that the ME should not give any other information to the 
user during the user confirmation phase. If an icon is provided by the UICC, the icon indicated in the 
command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as 
indicated with the icon qualifier (see subclause 6.5.4); 

if the alpha identifier is not provided by the UICC or is a null data object (i.e. length = '00' and no value part), 
the ME may give information to the user. 

if the user accepts the channel, the ME shall then set up a channel; 

if the user does not accept the channel or rejects the channel, then the ME informs the UICC using TERMINAL 
RESPONSE (user did not accept the proactive command). The operation is aborted; 

if the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with (Proactive UICC session terminated by the user) result value; 

optionally, during call set-up, the ME can give some audible or display indication concerning what is happening; 

if the first link set-up attempt is unsuccessful: 

if the UICC did not request link re -connection then the ME shall inform the UICC using TERMINAL 
RESPONSE (network currently unable to process command), and not retry to set-up the link: 

if the UICC requested link re-connection, then the ME may automatically retry to set-up the link (depending 
on its configuration capabilities). In this case, the ME shall not send a command result to the UICC 
concerning the first or any subsequent failed set-up attempts. If the link set-up has not been successful, and 
the ME is not going to perform any more re-tries, or the time elapsed since the first link set-up attempt has 
exceeded the duration requested by the UICC, then the ME shall inform the UICC using TERMINAL 
RESPONSE (network currently unable to process command), and the re-try mechanism shall be terminated; 

if the user stops the link set-up attempt or the re-try mechanism before a result is received from the network, 
the ME informs the UICC using TERMINAL RESPONSE (user cleared down call before connection or 
network release). 
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If the ME supports the Last Number Dialled service, the ME shall not store in EFlnd the channel set-up details (called 
party number and associated parameters) sent by the UICC in this command. 

6.4.27.2 OPEN CHANNEL related to GPRS 

This subclause applies only if class "e" is supported. 

Upon receiving this command, the ME shall decide if it is able to execute the command. The UICC shall indicate 
whether the ME should establish the link immediately or upon receiving the first transmitted data (on demand). 

The UICC provides to the ME a list of parameters necessary to activate a PDP context. 

The ME shall attempt at least one PDP context activation. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

if immediate PDP context activation is requested and the ME is unable to set-up a channel using the exact 
parameters provided by the UICC, the ME sets up the channel using the best parameters it can support and 
informs the UICC of the channel identifier and the modified parameters using TERMINAL RESPONSE 
(Command performed with modification); 

if immediate PDP context activation is requested and the ME is unable to activate the PDP context with the 
network using the exact parameters provided by the UICC, the ME informs the UICC using TERMINAL 
RESPONSE (Network currently unable to process command). The operation is aborted; 

if on demand link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the UICC, the ME sets up the channel using the best parameters it can support and informs the 
UICC of the channel identifier and the modified parameters using TERMINAL RESPONSE (Command 
performed with modification); 

if the command is rejected because the ME has no channel left with the requested bearer capabilities, the ME 
informs the UICC using TERMINAL RESPONSE (Bearer independent protocol error). The operation is aborted; 

- if the user does not accept the channel set-up, the ME informs the UICC using TERMINAL RESPONSE (User 
did not accept the proactive command). The operation is aborted; 

if the user has indicated the need to end the proactive UICC session, the ME informs the UICC using 
TERMINAL RESPONSE(Proactive UICC session terminated by the user). The operation is aborted; 

if the command is rejected because the class B ME is busy on a call, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on call). The operation is aborted; 

if the command is rejected because the class B ME is busy on a SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction). The operation is 
aborted. 

The ME shall inform the UICC that the command has been successfully executed using TERMINAL RESPONSE: 

if immediate PDP context activation is requested, the ME allocates buffers, activates the PDP context and 
informs the UICC and reports the channel identifier using TERMINAL RESPONSE (Command performed 
successfully); 

if on demand PDP context activation is requested, the ME allocates buffers, informs the UICC and reports the 
channel identifier using TERMINAL RESPONSE (Command performed successfully). 

If the ME is able to set up the channel on the serving network, the ME shall: 

alert the user (as for an incoming call). This is the confirmation phase; 

optionally, the UICC may include in this command an alpha-identifier. The use of this alpha-identifier by the 
ME is described below: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it during the 
user confirmation phase. This is also an indication that the ME should not give any other information to the 
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user during the user confirmation phase. If an icon is provided by the UICC, the icon indicated in the 
command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as 
indicated with the icon quaUfier (see subclause 6.5.4); 

if the alpha identifier is not provided by the UICC or is a null data object (i.e. length = '00' and no value part), 
the ME may give information to the user. 

if the user accepts the channel, the ME shall then set up a channel; 

if the user does not accept the channel or rejects the channel, then the ME informs the UICC using TERMINAL 
RESPONSE (user did not accept the proactive command). The operation is aborted; 

- if the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with (Proactive UICC session terminated by the user) result value; 

optionally, during PDP context activation, the ME can give some audible or display indication concerning what 
is happening; 

if the user stops the PDP context activation attempt before a result is received from the network, the ME informs 
the UICC using TERMINAL RESPONSE (user cleared down call before connection or network release). 

6.4.27.3 OPEN CHANNEL related to local bearer 

This subclause applies if classes "e" and "f" are supported. 

This command is used to establish a connection using a local bearer (Bluetooth, IrDA, RS232, USB). The UICC can act 
as a server or a client. In the server use case, the UICC performs an OPEN CHANNEL only after having received a 
Local Connection event from the ME. 

Upon receiving this command, the ME shall decide if it is able to execute the command. The UICC shall indicate 
whether the ME should establish the link immediately or upon receiving the first transmitted data (on demand). 

The UICC provides to the ME a list of parameters necessary to establish a link. 

The UICC may request the use of an automatic reconnection mechanism. The UICC may also request an optional 
maximum duration for the reconnection mechanism. The ME shall attempt at least one link establishment set-up. 

The UICC may also request an optional maximum duration for the ME to automatically release the link if no data is 
exchanged. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

if immediate link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the UICC, the ME sets up the channel using the best parameters it can support and informs the 
UICC of the channel identifier and the modified parameters using TERMINAL RESPONSE (Command 
performed with modification); 

- if immediate link establishment is requested and the ME is unable to set-up the link with the network using the 
exact parameters provided by the UICC, the ME informs the UICC using TERMINAL RESPONSE (Network 
currently unable to process command). The operation is aborted; 

if on demand link establishment is requested and the ME is unable to set-up a channel using the exact parameters 
provided by the UICC, the ME sets up the channel using the best parameters it can support and informs the 
UICC of the channel identifier and the modified parameters using TERMINAL RESPONSE (Command 
performed with modification); 

if the command is rejected because the ME has no channel left with the requested bearer capabilities, the ME 
informs the UICC using TERMINAL RESPONSE (Bearer independent protocol error). The operation is aborted; 

- if the user does not accept the channel set-up, the ME informs the UICC using TERMINAL RESPONSE (User 
did not accept the proactive command). The operation is aborted; 

if the user has indicated the need to end the proactive UICC session, the ME informs the UICC using 
TERMINAL RESPONSE(Proactive UICC session terminated by the user). The operation is aborted; 
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if the command is rejected because the ME is busy on another call, the ME informs the UICC using TERMINAL 
RESPONSE (ME unable to process command - currently busy on call). The operation is aborted; 

if the command is rejected because the ME is busy on a SS transaction, the ME informs the UICC using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction). The operation is 
aborted. 

The ME shall inform the UICC that the command has been successfully executed using TERMINAL RESPONSE: 

if immediate link establishment is requested, the ME allocates buffers, sets up the link and informs the UICC and 
reports the channel identifier using TERMINAL RESPONSE (Command performed successfully); 

if on demand link establishment is requested, the ME allocates buffers, informs the UICC and reports the 
channel identifier using TERMINAL RESPONSE (Command performed successfully). 

If the ME is able to set up the channel on the requested local bearer, the ME shall: 

alert the user (as for an incoming call). This is the confirmation phase; 

optionally, the UICC may include in this command an alpha-identifier. The use of this alpha-identifier by the 
ME is described below: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it during the 
user confirmation phase. This is also an indication that the ME should not give any other information to the 
user during the user confirmation phase. If an icon is provided by the UICC, the icon indicated in the 
command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as 
indicated with the icon qualifier (see subclause 6.5.4); 

if the alpha identifier is not provided by the UICC or is a null data object (i.e. length = '00' and no value part), 
the ME may give information to the user. 

if the user accepts the channel, the ME shall then set up a channel; 

if the user does not accept the channel or rejects the channel, then the ME informs the UICC using TERMINAL 
RESPONSE (user did not accept the proactive command). The operation is aborted; 

if the user has indicated the need to end the proactive UICC session, the ME shall send a TERMINAL 
RESPONSE with (Proactive UICC session terminated by the user) result value; 

optionally, during call set-up, the ME can give some audible or display indication concerning what is happening; 

if the first link set-up attempt is unsuccessful: 

if the UICC did not request link re-connection then the ME shall inform the UICC using TERMINAL 
RESPONSE (network currently unable to process command), and not retry to set-up the link: 

if the UICC requested link re-connection, then the ME may automatically retry to set-up the link (depending 
on its configuration capabilities). In this case, the ME shall not send a command result to the UICC 
concerning the first or any subsequent failed set-up attempts. If the link set-up has not been successful, and 
the ME is not going to perform any more re-tries, or the time elapsed since the first link set-up attempt has 
exceeded the duration requested by the UICC, then the ME shall inform the UICC using TERMINAL 
RESPONSE (network currently unable to process command), and the re-try mechanism shall be terminated; 

if the user stops the link set-up attempt or the re-try mechanism before a result is received from the network, 
the ME informs the UICC using TERMINAL RESPONSE (user cleared down call before connection or 
network release). 

6.4.28 CLOSE CHANNEL 

This subclause applies only if class "e" is supported. 

This command requests the ME to close the channel corresponding to the Channel identifier. 

Upon receiving this command, the ME shall decide if it is able to execute the command: 
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if the command is rejected because the channel identifier is not vaHd, the ME informs the UICC using 
TERMINAL RESPONSE (Bearer independent protocol error); 

if the command is rejected because the requested channel is in error, the ME informs the UICC using 
TERMINAL RESPONSE (Bearer independent protocol error). 

If the ME is able to process the command: 

the ME shall release the data transfer, discard the remaining data and inform the UICC that the command has 
been successfully executed, using TERMINAL RESPONSE; 

optionally, during CLOSE CHANNEL, the ME can give some audible or display indication concerning what is 
happening. In this intention, the UICC may include in this command an alpha-identifier. The use of this alpha- 
identifier by the ME is described below: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to indicate the 
link closing phase. If an icon is provided by the UICC, the icon indicated in the command may be used by the 
ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier 
(see subclause 6.5.4); 

if the alpha identifier is not provided by the UICC or is a null data object (i.e. length = '00' and no value part), 
the ME may give information to the user. 

6.4.29 RECEIVE DATA 

This subclause applies only if class "e" is supported. 

This command requests the ME to return data from a dedicated Channel identifier according to the number of bytes 
specified by the UICC. 

Upon receiving this command, the ME shall return the data available in the Rx buffer corresponding to the Channel 
identifier. Examples are given below, but the list is not exhaustive. 

If the ME is unable to process the command: 

if the command is rejected because the requested channel is already closed the ME informs the UICC using 
TERMINAL RESPONSE (Bearer independent protocol error); 

if the user has indicated the need to end the proactive UICC session, the ME informs the UICC using 
TERMINAL RESPONSE (Proactive UICC session terminated by the user). 

If the ME is able to process the command: 

if the requested number of bytes is available in the buffer, the ME shall inform the UICC that the command has 
been successfully executed, using TERMINAL RESPONSE and return the requested data and the number of 
bytes remaining in the channel buffer (or FF if more than the maximum bytes remains); 

if the requested number of bytes is not yet available in the buffer, the ME shall NOT wait for the requested 
number of bytes to arrive. The ME shall inform the UICC, using TERMINAL RESPONSE (Command 
performed with missing information) and returns the data currently available in the channel buffer; 

in the case of packet/datagram transmission, the ME shall put in the Rx buffer a complete packet SDU and only 
one at one time. For example, if UDP datagrams are received by the ME, the latter shall insert only the SDU of 
each UDP packet received in the Rx buffer. After one SDU has been downloaded by the UICC (using one or 
several RECEIVE DATA commands), the ME shall insert the next SDU of UDP datagram, and so on; 

if the alpha identifier is provided by the UICC, the ME shall use it to inform the user. The ME may also use it to 
inform the user during data transfer. If an icon is provided by the UICC, the icon indicated in the command may 
be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon 
qualifier (see subclause 6.5.4). 

6.4.30 SEND DATA 

This subclause applies only if class "e" is supported. 
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This command requests the ME to send data through a previously set up data channel corresponding to a dedicated 
Channel identifier. The UICC informs the ME if the data is: 

to be sent immediately; 

or to be stored in a Tx buffer. Then it is up to the ME to manage the data sending in order to use the bearer in an 
optimised way. To send the data stored in a Tx buffer, the ME shall be notified by a "send data immediately" and 
it shall consider the data presently and previously concatenated in its Tx buffer as one SDU, and send it in only 
one PDU. The Tx buffer shall then be emptied before returning the TERMINAL RESPONSE to the UICC and 
allowing new UICC sending. 

Upon receiving this command, the ME shall either immediatly send data or store provided data into the Tx buffer 
corresponding to the Channel identifier. Examples are given below, but the list is not exhaustive. 

If the ME is unable to process the command: 

if the command is rejected because the requested channel is already closed the ME informs the UICC using 
TERMINAL RESPONSE (Bearer Independent Protocol error); 

if the command is rejected because the channel is temporarily unavailable the ME informs the UICC using 
TERMINAL RESPONSE (ME currently unable to process command); 

if the requested number of bytes of empty space is not yet available in the buffer the ME informs the UICC using 
TERMINAL RESPONSE (Bearer Independent Protocol error); 

if the user has indicated the need to end the proactive UICC session, the ME informs the UICC using 
TERMINAL RESPONSE (Proactive UICC session terminated by the user). 

If the ME is able to process the command: 

if the requested number of bytes of empty space is available in the buffer the ME shall inform the UICC that the 
command has been successfully executed, using TERMINAL RESPONSE and return the number of bytes of 
empty space available in the Tx buffer (or FF if more then 255 bytes are available); 

in the case of packet/datagram transmission, the structure of the SDU sent by the UICC to the ME shall be fully 
respected while sending to the ME external interface. The size of the SDU is therefore limited by the size of the 
packet PDU sent over the ME external interface. In order to send one complete SDU, the USAT application may 
fill the Tx buffer with several SEND DATA commands, if necessary . Then the ME shall send the complete 
SDU in one packet PDU. 

if the alpha identifier is provided by the UICC, the ME shall use it to inform the user. The ME may also use it to 
inform the user during data transfer. If an icon is provided by the UICC, the icon indicated in the command may 
be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon 
qualifier (see subclause 6.5.4). 

6.4.31 GET CHANNEL STATUS 

This subclause applies only if class "e" is supported. 

This command requests the ME to return a Channel status data object for each dedicated Channel identifier. 

The ME shall return the requested information concerning the channel(s) within a TERMINAL RESPONSE command. 

6.4.32 DECLARE SERVICE 

This subclause applies only if class "f is supported. 

This command allows the UICC to download into the ME service database the services that the card provides as a 
server. The declaration is to be made on a service by service basis, at the set up (e.g. after the profile download). The 
UICC shall indicate whether the ME is required to add a new service in the ME service database or to remove a service 
from the ME service database. 

When adding a new service, the UICC shall provide a Service Record that the ME is required to register into its local 
service database. 
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When removing a service, the UICC shall provide the Service Identifier which uniquely identifies the service to be 
deleted from the database. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

If the command is rejected because the ME is busy on a call, the ME informs the UICC using TERMINAL 
RESPONSE (ME unable to process command - ME currently busy on call). 

If the command is rejected because the ME has not enough memory available to store the service record, the ME 
informs the UICC using TERMINAL RESPONSE(Bearer Independent Protocol Error - Requested buffer size 
not available). 

If the command for deletion is rejected because the service identifier is not valid, the ME informs the UICC 
using TERMINAL RESPONSE(Bearer Independent Protocol Error- Service identifier unknown) 

If the command is performed with modification of certain parameters of the Service Record (of which value is 
dynamically assigned by the ME), the ME informs the UICC using TERMINAL RESPONSE (command 
performed with modification). 

If the ME is able to execute the command: 

The ME shall inform the UICC that the command has been successfully performed using TERMINAL 
RESPONSE (command performed successfully). 

When performing a DECLARE SERVICE for deletion, if the UICC provides a Service Identifier parameter 
different from 'FF', the ME shall ignore the parameter and proceed with the command. 

Note that a service can be coded using a coding type issued from a specific local bearer technology (e.g. Bluetooth or 
IrDA); however this service shall be considered by the ME as available for any bearer. 

6.4.33 SERVICE SEARCH 

This subclause applies if class "f" is supported. 

This command is used to search for the availability of a service in the environment of the ME. 

The UICC may provide a Device Filter. The devices responding to the service search shall then be part of the set given 
by Device Filter. If the Device Filter parameter is not present, no filter on the type of equipment is done by the ME. 

The UICC provides a Service Search parameter. The devices responding to the service search shall then support the 
requested service. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

If the command is rejected because the ME is busy on a call, the ME informs the UICC using TERMINAL 
RESPONSE (ME unable to process command - ME currently busy on call). 

If the command is rejected because the bearer provided in the command is not available, the ME informs the 
UICC using TERMINAL RESPONSE(ME unable to process command - bearer unavailable) 

If the ME is able to execute the command: 

the ME performs the service search, gathers all received responses and informs the UICC using 
TERMINAL RESPONSE(command performed successfully. Service Availability). 

If the command fails because no device in the radio range supported the requested service, the ME informs 
the UICC using TERMINAL RESPONSE (Bearer independent protocol error - Service error). 

If the command fails because there is no device reachable, the ME informs the UICC using TERMINAL 
RESPONSE (Bearer independent protocol error - Remote device is not reachable). 
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6.4.34 GET SERVICE INFORMATION 

This subclause applies if class "f" is supported. 

This proactive command is used to look for the complete service record related to a service. By service record, it is 
meant all information that allows the UICC to define precisely the service (e.g. protocol stacks). 

The UICC provides the Attribute Information parameter which indicates which detailed information is required. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

If the command is rejected because the ME is busy on a call, the ME informs the UICC using TERMINAL 
RESPONSE (ME unable to process command - ME currently busy on call). 

If the command is rejected because the bearer provided in the command is not available, the ME informs the 
UICC using TERMINAL RESPONSE(ME unable to process command - bearer unavailable) 

If the ME is able to execute the command: 

the ME performs the search for the service details and informs the UICC using TERMINAL 
RESPONSE(command performed successfully. Service Record). The Service Record shall then be used as 
argument of an Open Channel proactive command. 

If the command fails because there is no device reachable, the ME informs the UICC using TERMINAL 
RESPONSE (Bearer independent protocol error - Remote device is not reachable). 

If the US AT application already has all information concerning the service, it may directly try to connect the service 
performing an OPEN CHANNEL, and bypass the GET SERVICE INFORMATION step. 

6.5 Common elements in proactive UICC commands 

6.5.1 Command number 

The command number is to cater for the future possibility of multiple ongoing commands (i.e. when the UICC issues 
further commands before receiving the response to the ongoing command). The implications of such multiple ongoing 
commands have not been elaborated at this stage of the toolkit specification. 

Each command issued by a proactive UICC during a 3G session shall have its own command number. Command 
numbers may take any hexadecimal value between '01' and 'FE'. The command number is held in the command details 
data object. 

The UICC is responsible for assigning the command number. 

The ME shall keep a record of the status of each command and its command number, until the ME gives the result of 
the command to the UICC, using TERMINAL RESPONSE. After this, the ME may erase all internal records 
concerning this command. The command number is then free for allocation by the UICC to a new command. 

When the UE is powered off and on, the details of any ongoing command shall be reset. The ME shall not be expected 
to know the status of commands issued in a previous 3G session. 

6.5.2 Device identities 

This data object gives the devices which are the source and destination for the instruction. Only certain combinations of 
source and destination devices are allowed for each proactive command. These are given in clause 10 of the present 
document. 



6.5.3 Alpha identifier 



Many of the commands include an alpha identifier data object. The text it contains shall be displayed on screen by the 
ME at the same time as the UICC command is performed. 
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6.5.4 Icon identifiers 

Some commands may provide an icon identifier. Icons are intended to enhance the MMI by providing graphical 
information to the user. The display of icons is optional for the ME. If icons are provided by the UICC, the related alpha 
identifier or text string shall be present and not a null string. 

The UICC indicates to the ME whether the icon replaces an alpha identifier or text string, or whether it accompanies it 
(see subclause 8.32). 

If both an alpha identifier or text string, and an icon are provided with a proactive command, and both are requested to 
be displayed, but the ME is not able to display both together on the screen, then the alpha identifier or text string takes 
precedence over the icon. 

If the UICC provides an icon identifier with a proactive command, then the ME shall inform the UICC if the icon could 
not be displayed by sending the general result "Command performed successfully, but requested icon could not be 
displayed". 

If the ME receives an icon qualifier with bit 1 set to 0, meaning "an alpha identifier or text string related to the icon may 
be displayed together with the icon by the ME" (see subclause 8.32), and no alpha identifier/text string is given by the 
UICC, than the ME shall reject the command with general result "Command data not understood by ME". 

NOTE: Application designers should be aware that icons provided by the application may not be displayed by the 
ME. 

6.6 Structure of proactive UICC commands 

The general structure of proactive UICC commands using TLV objects is described in annex C. 

6.6.1 DISPLAY TEXT 



Description 


Subclause 


IW/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Text string 


8.15 


M 


Y 


C 


Icon identifier 


8.31 





N 


D 


Immediate response 


8.43 





N 


E 


Duration 


8.8 





N 


F 



Duration: 

Contents: the required duration for execution of the command before the timeout expires. Resolution and the 
precision of the time value are in accordance with subclause 6.4.21 Timer Management 

6.6.2 GET INKEY 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Text string 


8.15 


M 


Y 


C 


Icon identifier 


8.31 





N 


D 


Duration 


8.8 





N 


E 



Text string: 

Contents: text for the ME to display in conjunction with asking the user to respond. 
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- Duration: 

Contents: the duration for execution of the command before the timeout expires. Resolution and the precision 
of the time value are in accordance with subclause 6.4.21 Timer Management. 

6.6.3 GET INPUT 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Text string 


8.15 


M 


Y 


C 


Response lengtli 


8.11 


M 


Y 


D 


Default Text 


8.23 





N 


E 


Icon identifier 


8.31 





N 


F 



Text string: 

Contents: text for the ME to display in conjunction with asking the user to respond. 

Response length: 

Contents: the minimum and maximum acceptable lengths in characters (see subclause 6.4.3) for the response 
from the user. 

- Default Text: 

Contents: text for the ME to display, corresponds to a default text string offered by the UICC. 

6.6.4 MORE TIME 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 



6.6.5 PLAY TONE 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Tone 


8.16 





N 


D 


Duration 


8.8 





N 


E 


Icon identifier 


8.31 





N 


F 



Tone: 

Contents: the standard supervisory tone or proprietary ME tone that the ME shall generate, either on its own 
or on top of the downlink audio path. If no tone is specified, then the ME shall default to "general beep". 

NOTE: Some supervisory tones are optional for mobile equipment (see TS 22.001 [22]). 

- Duration: 
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Contents: the length of time for which the ME shall generate the tone, if the tone is continuous or repeatable. 
For single tones, the value of this data object shall be ignored by the ME. If no duration is specified, the ME 
shall default to a duration determined by the ME manufacturer. 

6.6.6 POLL INTERVAL 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Duration 


8.8 


M 


Y 


C 



Duration: 

Contents: the maximum interval between two STATUS commands related to Proactive Polling. 

6.6.7 SET-UP MENU 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D1+D2+...Dn+E+F+G) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 


M 


Y 


C 


Item data object for item 1 


8.9 


M 


Y 


D1 


Item data object for item 2 


8.9 





N 


D2 




8.9 





N 


Dx 


Item data object for last item in list 


8.9 





N 


Dn 


Items Next Action Indicator 


8.24 





N 


E 


Icon identifier 


8.31 





N 


F 


Item Icon identifier list 


8.32 





N 


G 



The SET-UP MENU command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each Item data 
object contains an item in the list, for the user to choose. The length of each Item data object may be different. Within a 
list, each Item shall have a unique item identifier. 

If the "Item data object for item 1" is a null data object (i.e. length = '00' and no value part), this is an indication to the 
ME to remove the existing menu from the menu system in the ME. 

If the UICC provides an Items Next Action Indicator data object, the comprehension required flag shall be set to '0'. 

The UICC may provide a title icon identifier data object and/or an item icon identifier list data object. The item icon 
identifier data object contains an icon identifier for each item. 
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6.6.8 SELECT ITEM 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D1+D2+...Dn+E+F+G+H) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Item data object for item 1 


8.9 


M 


Y 


D1 


Item data object for item 2 


8.9 





N 


D2 




8.9 





N 


Dx 


Item data object for last item in list 


8.9 





N 


Dn 


Items Next Action Indicator 


8.24 





N 


E 


Item Identifier 


8.10 





N 


F 


Icon identifier 


8.31 





N 


G 


Item Icon identifier list 


8.32 





N 


H 



The SELECT ITEM command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each Item data 
object contains an item in the list, for the user to choose. The length of each Item data object may be different. Within a 
list, each Item shall have a unique item identifier. The SELECT ITEM command BER-TLV data object may contain a 
single Item Identifier data object as an indication of the default item. The Comprehension Required flag in the Item 
Identifier data object shall be set to 0, indicating that it is not mandatory for the ME to support indication of the default 
item. 

If the UICC provides an Items Next Action Indicator data object, the comprehension required flag shall be set to '0'. 

The UICC may provide a title icon identifier data object and/or an item icon identifier list data object. The item icon 
identifier data object contains an icon identifier for each item. 

6.6.9 SEND SHORT MESSAGE 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+G+D+E+F) 


- 


M 


Y 


1 or 2 


Gommand details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


G 


Address 


8.1 





N 


D 


SMS TPDU (SMS-SUBMIT or SMS- 
GOMMAND) 


8.13 


M 


Y 


E 


Icon identifier 


8.31 





N 


F 



The address data object holds the RP_Destination_Address of the Service Centre. If no RP_Destination_Address is 
transferred, then the ME shall insert the default Service Centre address. 

6.6.10 SENDSS 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UIGG command Tag 


9.2 


M 


Y 


1 


Length (A+B+G+D+E) 


- 


M 


Y 


1 or 2 


Gommand details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


G 


SS string 


8.14 


M 


Y 


D 


Icon identifier 


8.31 





N 


E 
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6.6.11 SENDUSSD 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


USSD String 


8.17 


M 


Y 


D 


Icon identifier 


8.31 





N 


E 



6.6.12 SET UP CALL 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F+G+H+l+J) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier (user confirmation phase) 


8.2 





N 


C 


Address 


8.1 


M 


Y 


D 


Capability configuration parameters 


8.4 





N 


E 


Subaddress 


8.3 





N 


F 


Duration 


8.8 





N 


G 


Icon identifier (user confirmation phase) 


8.31 





N 


H 


Alpha identifier (call set up phase) 


8.2 





N 


1 


Icon identifier (call set up phase) 


8.31 





N 


J 



If the capability configuration parameters are not present, the ME shall assume the call is a speech call. 

If the subaddress is not present, the ME shall not provide a called party subaddress to the network. 

If the duration is not present, the UICC imposes no restrictions on the ME of the maximum duration of redials. 

6.6.13 REFRESH 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


File List 


8.18 


C 


N 


C 


AID 


8.60 





N 


D 



For the refresh modes "File Change Notification", "USIM Initialization and File Change Notification" and "3G Session 
Reset", the UICC shall supply a File List data object, indicating which EFs need to be refreshed. For other modes, 
inclusion of a File List is optional, and the ME shall ignore it. 

If an AID TLV is present, it indicates the USIM application which needs to be refreshed. If it is not present, the ME 
shall assume the current USIM application needs to be refreshed. 

6.6.14 POLLING OFF 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 
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6.6.15 PROVIDE LOCAL INFORMATION 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 



6.6.16 SET UP EVENT LIST 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Event list 


8.25 


M 


Y 


C 



If the Event list is a null data object (i.e. length : 
existing list of events in the ME. 



'00' and no value part), this is an indication to the ME to remove the 



6.6.1 7 PERFORM CARD APDU 



Description 


Subclause 


IM/O/C 


lUlin 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


C-APDU 


8.35 


M 


Y 


C 



6.6.18 POWER OFF CARD 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 



6.6.19 POWER ON CARD 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 



6.6.20 GET READER STATUS 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 
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6.6.21 TIMER MANAGEMENT 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Timer Identifier 


8.37 


M 


Y 


C 


Timer value 


8.38 


C 


N 


D 



Timer Identifier: 

Contents: identifier of the timer to which the command appHes. 

Timer value: 

Contents: length of time during which the timer has to run. The UICC shall supply this data object only when 
a timer has to be started. 

6.6.22 SET UP IDLE MODE TEXT 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


8.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


7.5.6 


M 


Y 


A 


Device identities 


7.5.7 


M 


Y 


B 


Text string 


7.5.15 


M 


Y 


C 


Icon identifier 


8.31 





N 


D 



If the "Text string" is a null data object (i.e. length : 
text in the ME. 



'00' and no value part), the ME shall remove the existing idle mode 



6.6.23 RUN AT COMMAND 



Description 


Subclause 


IW/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Alpha Identifier 


8.2 





N 


C 


AT Command 


8.40 


M 


Y 


D 


Icon identifier 


8.31 





N 


E 



6.6.24 SEND DTMF COMMAND 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Alpha Identifier 


8.2 





N 


C 


DTMF String 


8.44 


M 


Y 


D 


Icon identifier 


8.31 





N 


E 
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6.6.25 LANGUAGE NOTIFICATION 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Language 


8.45 


C 


Y/N 


C 



Language: 

- Contents: Currently used language. The UICC shall include a Language object, when a specific language is 
being notified. 

6.6.26 LAUNCH BROWSER 



Description 


Subclause 


M/0 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F1 + 
F2+...+FN+G+H+I) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Browser Identity 


8.47 





N 


C 


URL 


8.48 


M 


Y 


D 


Bearer 


8.49 





N 


E 


Provisioning File Reference 1 


8.50 





N 


F1 


Provisioning File Reference 2 


8.50 





N 


F2 




8.50 





N 


Fx 


Provisioning File Reference N 


8.50 





N 


FN 


Text String (Gateway/Proxy Identity) 


8.15 





N 


G 


Alpha identifier (user confirmation phase) 


8.2 





N 


H 


Icon identifier (user confirmation phase) 


8.31 





N 


1 



If the URL data object is provisioned the URL value shall take precedence over any other URL value. 

If Provisioning File Reference data object is present in the command then it shall take precedence over Bearer and 
Proxy Identity. If several Provisioning File References are present in the same command the information in the first 
reference shall take precedence. 

Gateway/Proxy Identity is a text string which gives to the mobile the name/identity of the Gateway/Proxy to be used for 
connecting to the URL. This Gateway/Proxy Identity is required when the bearer data object is present. 



£75/ 



3GPP TS 31.111 version 4.3.0 Release 4 



59 



ETSI TS 131 111 V4.3.0 (2001-06) 



6.6.27 OPEN CHANNEL 



6.6.27.1 



OPEN CHANNEL related to CS bearer 



Description 


Subclause 


M/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F+G+H+l+J+K+L+M+N+0) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Address 


8.1 


M 


Y 


E 


Subaddress 


8.3 





N 


F 


Duration 1 


8.8 


C 


N 


G 


Duration 2 


8.8 





N 


H 


Bearer description 


8.52 


M 


Y 


1 


Buffer size 


8.55 


M 


Y 


J 


Other address (local address) 


8.58 





N 


K 


Text String (User login) 


8.15 





N 


L 


Text String (User password) 


8.15 





N 


M 


SIIVI/ME interface transport level 


8.59 





N 


N 


Data destination address 


8.58 


C 


Y 






The subaddress may be requested. If the subaddress is not present, the ME shall not provide a called party subaddress to 
the network. 

Duration 1 indicates the duration of reconnection tries. If Duration 1 is not present or is null, the UICC imposes no 
restrictions on the ME. Duration 1 shall be present if Duration 2 is present. 

Duration 2 indicates the timeout value before the ME releases the link if there is no data exchanged on the link. If 
duration 2 is not present the link is never released automatically by the ME. 

The local address parameter (see 8.58) provides information to the ME necessary to identify the local device (i.e. it 
provides an IP address). If local address length is null, dynamic local address is required. If parameter is not present, the 
mobile may use the mobile default local address configuration. 

The ME may support a remote access login feature (e.g. PPP login). If supported by the ME, the UICC may provide 
"User login" and "User password" parameters which allow the ME to answer an access authentication challenge . If 
only one parameter is present, it is considered as the User Login and the ME shall use default Password configuration if 
any. If the parameters are not present, the ME shall use default Login/Password configuration if any. If no 
authentication challenge is requested, the user login and password parameters shall be ignored. 

If the SIM/ME interface transport level is present in the command, then the ME shall provide the requested transport 
layer protocols under the channel and shall use this object containing a set of parameters required to make the transport 
connection. The data that is exchanged at the SIM/ME interface in the RECEIVE DATA/SEND DATA commands are 
SDUs. When the USAT application sends an SDU, the transport layer within the ME is in charge to add the transport 
header to the SDU in order to build the Transport-PDU. When the USAT application requests to receive an SDU, the 
transport layer within the ME is in charge to remove the transport header of the Transport-PDU, and to forward the 
SDU to the USAT. If the parameter is not present, the SIM/ME interface is the bearer level (serial link or packet link as 
defined in TS 27.007 [12]) and the USAT application is in charge of the network and transport layer. 

The Data destination address is the end point destination address of sent data. This data destination address is requested 
when a SIM/ME interface transport is present, otherwise it is ignored. The data destination address is a data network 
address. 
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6.6.27.2 



OPEN CHANNEL related to GPRS 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F+G+H+l+J) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Bearer description 


8.52 


M 


Y 


E 


Buffer size 


8.55 


M 


Y 


F 


Access Point Name 


8.48 





N 


G 


Other address (local address) 


8.58 





N 


H 


SIIVI/ME interface transport level 


8.59 





N 


1 


Data destination address 


8.58 


C 


Y 


J 



The Access Point Name may be requested. The Access Point Name parameter is a URL (see 8.48) which provides 
information to the ME necessary to identify the Gateway GSN (GGSN) which provides interworking with an external 
packet data network. If the parameter is not present, the mobile may use the default Access Point Namein the mobile 
configuration or the default subscription value. 

The local address parameter (see 8.58) provides information to the ME necessary to identify the local device. If the 
parameter is present and length is not null, it provides an IP address that identifies the USAT application in the address 
area applicable to the PDN. If local address length is null, dynamic local address allocation is required for the SAT 
application. If parameter is not present, the mobile may use the mobile default local address configuration. 

If the SIM/ME interface transport level is present in the command, then the ME shall provide the requested transport 
layer protocols under the channel and shall use this object containing a set of parameters required to make the transport 
connection. The data that is exchanged at the SIM/ME interface in the RECEIVE DATA/SEND DATA commands are 
SDUs. When the USAT application sends an SDU, the transport layer within the ME is in charge to add the transport 
header to the SDU in order to build the Transport-PDU. When the SAT application requests to receive an SDU, the 
transport layer within the ME is in charge to remove the transport header of the Transport-PDU, and to forward the 
SDU to the USAT. If the parameter is not present, the SIM/ME interface is the bearer level (serial link or packet link as 
defined in TS 27.007 [12]), and the USAT application is in charge of the network and transport layer. 

The Data destination address is the end point destination address of sent data. This data destination address is requested 
when a SIM/ME interface transport is present, otherwise it is ignored. The data destination address is a data network 
address (e.g. IP address). 



6.6.27.3 



OPEN CHANNEL for local links 



Description 


Subclause 


IM/O/C 


Min 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+G+D+E+F+G+H+l+J+K+L) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Duration 1 


8.8 


C 


N 


E 


Duration 2 


8.8 





N 


F 


Bearer description 


8.52 


M 


Y 


G 


Buffer size 


8.55 


M 


N 


H 


Text String (User password) 


8.15 





N 


1 


SIIVI/ME interface transport level 


8.59 





N 


J 


Data destination address 


8.58 


C 


Y 


K 


Remote Entity Address 


8.68 





N 


L 



Duration 1 indicates the duration of reconnection tries. If Duration 1 is not present or is null, the UICC imposes no 
restrictions on the ME. Duration 1 shall be present if Duration 2 is present. 

Duration 2 indicates the timeout value before the ME releases the link if there is no data exchanged on the link. If 
duration 2 is not present the link is never released automatically by the ME. 



£75/ 



3GPP TS 31.111 version 4.3.0 Release 4 



61 



ETSI TS 131 111 V4.3.0 (2001-06) 



Bearer Description gives detailed information characterising the bearer. When the UICC acts as a server, local 
information (local service record data) is included in Bearer Description; in addition, if the UICC provides a Service 
Record field (which is part of the Bearer Description TLV) different from '00', the ME shall ignore it and proceed with 
the command. When the UICC acts as a client, remote information (remote service record data) is included in Bearer 
Description; in addition, if the UICC provides a Service Identifier field (which is part of the Bearer Description TLV) 
different from 'FF', the ME shall ignore it and proceed with the command. 

The UICC may optionally provide a user password that should be used by the ME for authentication. For the Bluetooth 
local bearer, the user password corresponds to the passkey/PIN as defined in [27]. 

If the SIM/ME interface transport level is present in the command, then the ME shall provide the requested transport 
layer protocols under the channel and shall use this object containing a set of parameters required to make the transport 
connection. If the parameter is not present, the SIM/ME interface is the bearer level. The data that will be received/sent 
from the SAT to the transport layer is a SDU that will be received/transmitted in the Transport-PDU. 

The Data destination address is the end point destination address of sent data. This data destination address is requested 
when a SIM/ME interface transport is present, otherwise it is ignored. The data destination address is a data network 
address (e.g. IP address). 

The Remote Entity Address parameter provides information to the ME necessary to identify the entity which provides 
access to the requested resource. Depending on the local technology, this parameter is necessary or not. For Bluetooth, 
it shall be the BD_ADDR of the remote device. 

6.6.28 CLOSE CHANNEL 



Description 


Subclause 


IM/O 


lUlin 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 



6.6.29 RECEIVE DATA 



Description 


Subclause 


M/0 


lUlin 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Channel data length 


8.54 


M 


Y 


E 



6.6.30 SEND DATA 



Description 


Subclause 


IVI/0 


IViin 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Channel data length 


8.54 


M 


Y 


E 


Channel data 


8.53 


M 


Y 


F 
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6.6.31 GET CHANNEL STATUS 



Description 


Subclause 


IUI/0 


lUlin 


Length 


Proactive UICC command Tag 


9.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 



6.6.32 SERVICE SEARCH 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


9.3 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Service search 


8.65 


M 


Y 


E 


Device filter 


8.64 





N 


F 



6.6.33 GET SERVICE INFORMATION 



Description 


Section 


IM/O 


lUlin 


Length 


Proactive SIM command Tag 


9.3 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Alpha identifier 


8.2 





N 


C 


Icon identifier 


8.31 





N 


D 


Attribute information 


8.66 


M 


Y 


E 



6.6.34 DECLARE SERVICE 



Description 


Section 


IM/O 


Min 


Length 


Proactive SIM command Tag 


9.3 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


8.6 


M 


Y 


A 


Device Identities 


8.7 


M 


Y 


B 


Service Record 


8.63 


M 


Y 


C 


SIM/ME interface 


8.59 





N 


D 



For Device identities field, Destination Device Identity is required to be the ME. 

The SIM/ME interface parameter specifies the protocol stack the UICC will be connected to on the ME. If the SIM/ME 
interface data object is not present, the SIM/ME interface is the bearer level as defined in the OPEN CHANNEL 
command. 
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6.7 Command results 

Once the ME has made its attempt to execute a proactive command from the UICC, the ME shall inform the UICC of 
the success or otherwise of that command, by using TERMINAL RESPONSE. This message gives the command 
details, including the number of the command (see subclause 6.5.1), a general result, and sometimes more specific 
information. 

Three overall categories of results are defined: 

command performed successfully. This is returned by the ME for every successful command; 

temporary problem with executing command. This is further defined below, but generally these indicate to the 
UICC that it is worth trying again later; 

- permanent problem with executing command. These are further defined below, but generally indicate that the 
same command will end in the same result if repeated during the same 3G session. 

Successful commands are further defined as: 

command performed successfully. There were no problems; 

command performed with partial comprehension. Here the ME receives a command with one or more SIMPLE- 
TLV data objects that are unrecognized or unexpected, all of which do not have their "comprehension required" 
flag set (subclause 9.3), but the parent BER-TLV data object still has the minimum set of SIMPLE-TLV data 
objects required to perform the command; 

command performed, with missing information. The ME received at least the minimum set of component parts, 
but did not receive all of the parts that it believed mandatory for the UICC to send; 

REFRESH performed with additional EFs read (see subclause 6.4.7); 

command performed successfully but requested icon could not be displayed; 

command performed, but modified by call control. This is sent by the ME to indicate that call control modified 
the type of request indicated in the proactive command, and that the action requested by call control was 
performed successfully; 

command performed with modification. This is sent by the ME to indicate that it is unable to process the 
command using the exact parameters provided by the UICC. The command is processed with the best possible 
parameters; 

command performed successfully, limited service; 

REFRESH performed but indicated USIM was not active. 

Temporary problems are further defined as: 

ME is currently unable to process the command. Specific causes for this are: 

the screen is busy; 

- ME currently busy on a call; 

- ME currently busy on SEND DTMF operation; 

- ME currently busy on SS transaction; 

- ME currently busy on USSD operation; 
no service is currently available; 

access control class barred on serving network; 
no radio resource currently available; 
not in speech call; 
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- no USIM active. 

if none of these can be made to apply, a "no cause can be given" value can be used; 

network is currently unable to process the command. Specific cause values are the cause values given by the 
network, as defined in 3G 24.008 [9]; 

in some proactive commands, the ME is required to solicit and receive approval of the user before executing the 
proactive command. In the case that the user does not give approval for the execution of the proactive 
command, it shall not be executed by the ME and the terminal response "user did not accept the proactive 
command" shall be returned by the ME to the UICC; 

- the user cleared down the call, before the call connected (CONNECT received from network, as defined in 
3G 24.008 [9]) or before the network released the call; 

action in contradiction with the current timer state. This is where the UICC requests an action for a timer to be 
taken by the ME and the state of the timer does not allow that action; 

interaction with call control by UICC, temporary problem. This is sent by the ME to indicate that call control 
modified the type of request indicated in the proactive command, and that the action requested by call control 
encounters a temporary problem. 

Permanent problems are further defined as: 

command is beyond ME's capabilities. This is sent by the ME when it understands what the UICC is asking it to 
do, but does not have the capability to do it, e.g. ME which only supports SMS asked to set up a call; 

command type not understood by ME. This is sent by the ME when the UICC sends a command with the Type 
of Command byte set to a value the ME does not know. This is to allow future expansion of commands; 

command data not understood by ME. This is sent by the ME when the command type is understood by the ME, 
but the related data object(s) are not, e.g. reserved values have been included in a data object, or one or more 
unknown SIMPLE-TLV data objects have a "comprehension required" tag; 

SS Return Error. This is given to the UICC when the network returns a SS error in response to a previous SS 
command. Specific cause values are the same as given by the network in the Return Error message; 

USSD Return Error. This is given to the UICC when the network returns a USSD error in response to a previous 
USSD command. Specific cause values are the same as given by the network in a Return Error message; 

SMS RP -ERROR. This is given to the UICC when the network returns an error in response to the ME trying to 
send a short message. Specific cause values are the same as the cause value of RP -Cause in an RP -ERROR 
message; 

error, required values are missing. This is given when the command type is understood by the ME, but it does 
not receive the minimum set of SIMPLE-TLV data objects that it requires to perform the command. These 
components are shown by the "Min" column in the command structure definitions; 

interaction with call control by USIM or MO short message control by USIM, permanent problem. This is sent 
by the ME to indicate that: 

call control by USIM does not allow the action corresponding to the proactive command; or 

call control by USIM has modified the type of request indicated in the proactive command and that the action 
requested by call control encounters a permanent problem. 

specific cause values for this are: 

action not allowed; 

the type of request has changed. 

Current Access Technology unable to process command. This is given to the USIM when ME is unable to 
process the requested command due to the current access technology in use. 

if none of these can be made to apply, a "no cause can be given" value can be used. 
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6.8 



Structure of TERMINAL RESPONSE 



Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. Length (A+B+ ... +Y) is indicated by P3 of the header. 

Command parameters/data. 



Description 


Subclause 


M/O/C 


MIn 


Length 


Command details 


8.6 


M 


Y 


A 


Device identities 


8.7 


M 


N 


B 


Result 


8.12 


M 


Y 


C 


Duration (only required in response to a 
POLL INTERVAL proactive command) 


8.8 


C 


N 


D 


Text string (only required in response to a 
GET INKEY or GET INPUT or SEND USSD 
proactive command) 


8.15 


C 


N 


E 


Item identifier (only required in response to 
SELECT ITEIVI proactive command) 


8.10 


C 


N 


F 


Local information (only required in response 
to PROVIDE LOCAL INFORMATION 
proactive command) 


8.19,8.20, 
8.22, 8.29, 
8.39, 8.45, 
8.46, 8.61 


C 


N 


G 


Call control requested action (only required 
if call control by USIM has modified a 
proactive command SET UP CALL, SEND 
SS or SEND USSD in another type of 
request). 


8.30 


C 


N 


H 


Result data object 2 (only required if call 
control by USIM has modified a proactive 
command SET UP CALL, SEND SS or 
SEND USSD in another type of request). 


8.12 


C 


N 


1 


Card reader status (only required in 
response to GET READER STATUS 
command). According to the requested 
information, one Card reader status object 
for each card interface reported, or one 
Card reader identifier object is required.. 


8.33, 8.57 


C 


N 


Jo + ... + Jn 

or J 


Card ATR (only required in response to 
POWER ON CARD). 


8.33 


C 


N 


K 


R-APDU (only required in response to 
PERFORM CARD APDU). 


8.36 


C 


N 


L 


Timer identifier (only required in response to 
a TIMER MANAGEMENT proactive 
command) 


8.37 


C 


N 


M 


Timer value (only required in response to a 
TIMER MANAGEMENT proactive 
command) 


8.38 


C 


N 


N 


AT Response (only required in response to 
RUN AT COMMAND proactive command) 


8.41 


C 


N 


P 


Text string2 (only required if call control by 
USIM has modified the proactive command 
SET UP CALL or SEND SS into a USSD 
request) 


8.15 


c 


N 





Channel data (only required in response to 
RECEIVE DATA) 


8.54 


c 


N 


R 


Channel status (only required in response to 
GET CHANNEL STATUS or OPEN 
CHANNEL proactive command) 


8.56 


c 


N 


So+ ... +Sn 


Channel data length (only required in 
response to RECEIVE DATA or SEND 
DATA proactive command) 


8.54 


c 


N 


T 
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Description 


Subclause 


M/O/C 


Min 


Length 


Bearer description (only required in 
response to OPEN CHANNEL proactive 
command) 


8.52 


C 


N 


U 


Buffer size (only required in response to 
OPEN CHANNEL proactive command) 


8.55 


c 


N 


V 


Total display duration (only required in 
response to a GET INKEY proactive 
command) 


8.8 


c 


N 


w 


Service availability (only required in 
response to SERVICE SEARCH proactive 
command) 


8.67 


c 


N 


X 


Service record (only required in response to 
GET SERVICE INFORMATION proactive 
command) 


8.63 


c 


N 


Y 



Under no circumstances shall the UICC wait indefinitely for a TERMINAL RESPONSE. 

For all the Conditional (C) SIMPLE-TLV objects, the ME should not include them in the response to non-applicable 
situations. However, if one is present, the UICC shall ignore it. 

For all SIMPLE-TLV objects with Min=N, the ME should set the CR flag to comprehension not required. Any future 
additional SIMPLE-TLV objects will be included as Min = N and comprehension not required. This will ensure that any 
proactive command will end in a predictable way. 

Response parameters/data: None. 

6.8.1 Command details 

This data object shall be identical to the command details data object (including the comprehension required flag) given 
by the UICC in the proactive command to which the ME is giving the result. 

- if the ME has not received a valid Command number, all Command Details object values shall be set to '00' and 
the Result shall indicate an error; 

if the failure is caused by a problem on the transmission layer, the ME shall respond with "temporary problem" 
("ME currently not able to process command"). If not, the ME shall respond with "permanent problem" (either 
"command not understood by ME" or "Error required values are missing"); 

the UICC shall interpret a Terminal Response with a command number '00' as belonging to the last proactive 
command having been sent to the ME. 

6.8.2 Device identities 

The ME shall set the device identities to: 
source: ME; 

destination: UICC. 

6.8.3 Result 

This data object holds the result of the proactive UICC command. 

6.8.4 Duration 

When the ME issues a successful TERMINAL RESPONSE for a POLL INTERVAL command, it shall state the polling 
interval it will be using in the Duration data object. 
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6.8.5 Text string 



When the ME issues a successful TERMINAL RESPONSE ('OX' resuh value - refer to subclause 8.12) for a GET 
INKEY or GET INPUT or SEND USSD command, it shall supply the single character or the character string entered by 
the user in the Text string data object, or the text returned within the Return Result message from the network for the 
USSD command, no matter what type of string was entered. When the ME issues a successful TERMINAL 
RESPONSE ('OX' result value - refer to subclause 8.12) for a GET INKEY ("Yes/No") command with command 
qualifier set to "Yes/No", it shall supply the value '01' when the answer is "positive" and the value '00' when the answer 
is "negative" in the Text string data object. 

When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 8.12) for a GET 
INPUT command to which the user has made an empty input (i.e. if the user does not enter any character), the ME shall 
indicate this by means of either a null text string (see subclause 8.15 for the coding of this object), or by means of a 
Text string object with Length = '01', and a Value part consisting of a data coding scheme only. 

NOTE: The notion of empty input is different from the general result 'no response from user' (see subclause 8.12). 
The latter event is typically caused by a timeout in the MMI, whereas an empty input requires an 
acknowledgement from the user. 

6.8.6 Item identifier 

When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 8.12) for a SELECT 
ITEM command, it shall supply the identifier of the item selected by the user in the Item identifier data object. If the 
ME issues a TERMINAL RESPONSE with result "Help information required by the user" for a SELECT ITEM 
command, it shall supply the identifier of the item for which the user is requiring help information. 

6.8.7 Local information 

When the ME issues a successful TERMINAL RESPONSE for a PROVIDE LOCAL INFORMATION command, it 
shall supply the requested local information. 

Where the UICC has requested location information, TERMINAL RESPONSE shall contain the location 
information data object. 

- Where the UICC has requested the IMEI, TERMINAL RESPONSE shall contain the IMEI data object. 

- Where the UICC has requested the Network Measurement Results the TERMINAL RESPONSE shall contain 
the NMR data object and the BCCH channel list data object. 

- Where the UICC has requested the date, time and time zone the TERMINAL RESPONSE shall contain the 
Date-Time and Time zone data object. 

Where the UICC has requested the currently used language, the TERMINAL RESPONSE shall contain the 
Language data object. 

- Where the UICC has requested the Timing Advance, the TERMINAL RESPONSE shall contain the Timing 
Advance data object. 

- Where the UICC has requested the Access Technology, the TERMINAL RESPONSE shall contain the Access 
Technology data object. 



6.8.8 Call control requested action 

When the ME issues a TERMINAL RESPONSE for a proactive command SET UP CALL, SEND SS or SEND USSD 
which has been modified by call control by UICC in another type of request, it shall supply the response data given in 
response to the ENVELOPE (CALL CONTROL). 

6.8.9 Result data object 2 

When the ME issues a TERMINAL RESPONSE for a proactive command SET UP CALL, SEND SS or SEND USSD 
which has been modified by call control by UICC in another type of request, it shall supply the Result data object it 
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would have supplied for the proactive command equivalent to the action requested by call control, and given in the Call 
control request data element. 

6.8.1 Card reader status 

This subclause applies if class "a" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a GET READER STATUS command, it shall supply 
the requested readers' information: 

- Where the UICC has requested the card reader status, TERMINAL RESPONSE shall supply the status of each 
card reader in n consecutive Card reader status data objects, where n is the card reader count. 

- Where the UICC has requested the card reader identifier, TERMINAL RESPONSE shall supply the identifier of 
the requested card reader identifier. 

6.8.11 CardATR 

This subclause applies if class "a" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a POWER ON CARD command, it shall supply the 
ATR returned by the addressed card in the Card ATR data object. 

6.8.12 R-APDU 

This subclause applies if class "a" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a PERFORM CARD APDU command, it shall supply 
the response data and status words in the R-APDU data object. 

6.8.13 Timer identifier 

When the ME issues a successful TERMINAL RESPONSE for a TIMER MANAGEMENT, it shall state in the timer 
identifier data object the identifier of the timer to which this command applies. 

6.8.14 Timer value 

When the ME issues a successful TERMINAL RESPONSE for a TIMER MANAGEMENT command with command 
qualifier indicating 'deactivate' or 'get the current value of the timer', it shall state in the timer value data object the 
current value of the timer. 

6.8.15 AT Response 

This subclause applies if class "b" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a RUN AT COMMAND command, the TERMINAL 
RESPONSE shall contain the AT Response (as defined in subclause 8.40). 



6.8.16 Text string 2 



When the ME issues a successful TERMINAL RESPONSE for a proactive command SET UP CALL or SEND SS 
which has been modified by "call control" by USIM into a USSD request ('05' result value), it shall supply the Text 
string 2. The Text string 2 shall contain the text returned within the Return Result message from the network for the 
USSD response. Text string 2 is equivalent to the Text string in the Terminal Response to a SEND USSD command. 

6.8.17 CInanneldata 

This subclause applies only if class "e" is supported. 
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When the ME issues a successful TERMINAL RESPONSE for a RECEIVE DATA command, the TERMINAL 
RESPONSE shall contain the Channel Data data object. 

6.8.18 Channel status 

This subclause applies only if class "e" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a GET CHANNEL STATUS proactive command, the 
TERMINAL RESPONSE shall contain as many Channel Status data objects as there are available channels. 

When the ME issues a successful TERMINAL RESPONSE for an OPEN CHANNEL command, the TERMINAL 
RESPONSE shall contain a Channel status data object for the opened channel. 

6.8.19 Channel data length 

This subclause applies only if class "e" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a RECEIVE DATA command or a SEND DATA, the 
TERMINAL RESPONSE shall contain the Channel Data Length data object. 

6.8.20 Bearer description 

This subclause applies only if class "e" is supported. 

When the ME issues a successful or an unsuccessful TERMINAL RESPONSE for an OPEN CHANNEL command, the 
TERMINAL RESPONSE shall contain the Bearer description data object. 

6.8.21 Buffer size 

This subclause applies only if class "e" is supported. 

When the ME issues a successful or an unsuccessful TERMINAL RESPONSE for a OPEN CHANNEL command, the 
TERMINAL RESPONSE shall contain the Buffer size data object. 

6.8.22 Total Display Duration 

When the ME issues a TERMINAL RESPONSE for a GET INKEY proactive command with variable timeout, it shall 
supply the total display text duration (command execution duration). The time unit of the response is identical to the 
time unit of the requested variable timeout. 

Resolution and the precision of the time value are in accordance with subclause 6.4.21 Timer Management. 

6.8.23 Service Availability 

This subclause applies if class "f" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a SERVICE SEARCH command, the TERMINAL 
RESPONSE shall contain the Service Availability data object. 

6.8.24 Service Record 

This subclause applies if class "f" is supported. 

When the ME issues a successful TERMINAL RESPONSE for a GET SERVICE INFORMATION command, the 
TERMINAL RESPONSE shall contain the Service Record data object. 
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6.9 Proactive UICC session and IVIE display interaction 

During a proactive session the ME display shall be refreshed by any display data contained in the first and each 
subsequent proactive command. The refresh shall occur once the ME has retrieved the proactive command using the 
Fetch instruction, fc)llowing the proactive command pending status response. 

If no proactive command is pending (status response of '90 00' following the Terminal Response), then the session 
releases the display back into ME control. If this session was terminated in a backwards move, and the session was 
initiated from an Envelope command containing a Menu Selection, it is recommended that the display returns to the 
Setup Menu. 

If the text is to be sustained, the ME shall display the text of applicable DISPLAY TEXT commands beyond the 
sending of the TERMINAL RESPONSE and possibly beyond the end of the proactive session. 

If a variable display timeout was indicated for a DISPLAY TEXT command, then the session releases the display back 
into ME control no later then the period stated by the duration. If the text is to be sustained beyond an immediate 
response, the ME shall display the text for a period that does not exceed the duration. 

6.10 Handling of unknown, unforeseen and erroneous messages 

6.10.1 General 

The procedures described in this subclause apply to the BER-TLV and SIMPLE-TLV data objects described in the 
present document. The purpose of this subclause is to allow greater flexibility in future versions of the present 
document, and a greater predictability across different versions of the present document. 

The procedures described here specify how the ME and UICC shall behave when they receive a proactive command or 
response that is not fully compliant with the standards by which it was designed. A response will be made to the UICC 
by means of the "general result" field of the "result" 

If the ME sends a FETCH or TERMINAL RESPONSE to the UICC that contains values that the UICC does not 
understand, then the UICC shall issue the appropriate SWl / SW2 error response. The current proactive transaction 
shall be considered complete and neither the ME or the UICC shall take no further action with regard to it. In this case, 
unless the "General result" is "command performed..." then the UICC shall assume that the command was not carried 
out and that a permanent error exists with regard to that particular proactive command. If the command was performed, 
but the "additional information on result" field was not understood, then the UICC may attempt the command again at a 
later stage in the current 3G session. 

If the UICC has enough information to proceed (i.e. it has received all the data objects of the Minimum set) then it shall 
do so. 

6. 1 0.2 IVIessage too short 

Any information received that is not a complete tag and length shall be ignored. 

6.10.3 IVIissing minimum information 

If a message is received that does not have all the mandatory elements in it, then if all of the minimum set elements are 
present then the receiver shall complete the command and report "command performed, with missing information". 

If the minimum set of elements is not complete, then the ME shall respond with "Error, required values are missing". 

6.1 0.4 Unknown Tag value 

If a BER-TLV object is received that has a tag that is understood, but contains SIMPLE-TLV components that have 
unknown tags, then provided the minimum set condition is fulfilled, the "comprehension required" bit of the tag shall 
determine how the receiving entity behaves. 



£75/ 



3GPP TS 31 .1 1 1 version 4.3.0 Release 4 71 ETSI TS 1 31 1 1 1 V4.3.0 (2001 -06) 

If the comprehension required flag in an unknown tag is set to '1', and the ME either does not recognize or is not 
expecting one or more of the SIMPLE-TLV objects in the message, then it shall respond with "Command data not 
understood by ME". 

If the comprehension required flag is set to '0', then the ME shall read the length field that follows and ignore that 
object. In this case the ME will be able to carry out the command without the SIMPLE-TLV components that it cannot 
understand. It shall respond with "command performed with partial comprehension ". 

6.1 0.5 Unexpected Tag value 

If a BER-TLV object is received that contains elements that have recognisable tags, but which where not expected in 
the context of this message (for example, the ME sees SMS TDPU tag as part of DISPLAY TEXT), then is shall discard 
that element. It shall then proceed as described for Unknown Tag values. 

If a received object has a tag that has already been received, then the first instance shall be used and any subsequent 
instances shall be discarded. 

6.10.6 Length errors 

If the total lengths of the SIMPLE-TLV data objects are not consistent with the length given in the BER-TLV data 
object, then the whole BER-TLV data object shall be rejected. The result field in the TERMINAL RESPONSE shall 
have the error condition "Command data not understood by ME". 

If the length of the BER-TLV data object is shorter than the length of the response data, the ME shall ignore response 
data following the complete BER-TLV data object. If the length of the BER-TLV data object is longer than the length 
of the response data, then subclauses 6.10.2. and 6.10.3 apply. 

6.1 0.7 Contents not understood 

If the contents of a SIMPLE-TLV data object contains a field with a value that is defined as reserved, then the whole 
SIMPLE-TLV data object shall be considered as invalid. It will then depend on the "comprehension required" bit of the 
relevant tag as to whether the whole BER-TLV data object shall be rejected, or whether that particular SIMPLE-TLV 
data object shall be ignored. 

If the contents of a BER-TLV object contains RFU bits or bytes, then these shall be ignored. 

6.1 0.8 Extended length data objects 

If a SIMPLE-TLV data object has a length longer than expected (i.e. more information has been added), then the 
receiver shall ignore this extra information to the end of the object. The end of the object shall be found by looking at 
the "length" field of that object. 

NOTE: If comprehension of the extra bytes is required, this can be achieved by the use of a reserved coding in an 
earlier field. 

6.1 1 Proactive commands versus possible Terminal response 

Table 6.1 shows for each proactive command the possible terminal response returned (marked by a "•" character). 
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Table 6.1 : Proactive commands versus possible Terminal response (continued overleaf...) 





PROACTIVE COMMAND 1 




RE- MORE 
FRESH TIME 

'01' '02' 


POLL POLL- 
INTER- !NG 
VAL OFF 

'03' '04' 


SETUP SET 
EVENT UP 
LIST CALL 

'05' '10' 


SEND SEND 
SS USSD 

'11' '12' 


SEND SEND 
SMS DTMF 

'13' '14' 


LAUNC PLAY 
H TONE 
BROW 
SER 

'15' '20' 


DIS- GET 
PLAY INKEY 
TEXT 

•21' '22' 


GET SEL- 

INPUT ECT 

ITEM 

'23' '24' 


SET UP PRO- 
MENU VIDE 
LOCAL 
INFO 

'25' '26' 


TIMER SETU 
MAN- P IDLE 
AGE- MODE 
MENT TEXT 

'27' '28' 


TERMINAL RESPONSE 


00 
01 


Command performed successfully 

Command performed with partial comprehension 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


02 
03 


Command performed, with missing information 
REFRESH performed with additional EFs read 


• • 
• 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


04 
05 


Command performed succesfully, but requested icon could not 

be displayed 
Command performed, but modified by call control by USIM 






• 
• 


• • 

• • 


• • 


• 


• • 


• • 


• 




06 
07 


Command performed successfully, limited service 
Command performed with modification 


















• 




08 
10 


REFRESH performed but indicated USIM was not active 
Proactive UIGG session terminated by the user 


• 




• 




• 


• 


• • 


• • 






11 
12 


Backward move in the proactive UIGG session requested by 

the user 
No response from user 














• • 

• • 


• • 

• • 






13 
14 


Help information required by the user 
USSD or SB Transaction terminated by user 






• 


• • 






• 


• • 






20 
21 


ME currently unable to process command 
Network currently unable to process command 


• • 


• • 


• • 
• 


• • 

• • 


• • 
• 


• • 
• 


• • 


• • 


• • 


• • 


22 
23 


User did not accept the proactive command 

User cleared down call before connection or network release 






• 
• 






• 










24 
25 


Action in contradiction with the current timer state 
Interaction with call control by USIM, temporary problem 






• 


• • 












• 


26 
30 


Launch browser generic error 
Command beyond MEs capabilities 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


• • 


31 
32 


Command type not understood by ME 
Command data not understood by ME 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


33 

34 


Command number not known by ME 
SS Return Error 


• • 


• • 


• • 
• 


• • 
• 


• • 


• • 


• • 


• • 


• • 


• • 


35 
36 


SMS RPERROR 

Error, required values are missing 


• • 


• • 


• • 


• • 


• 

• • 


• 


• • 


• • 


• • 


• • 


37 
38 


USSD return error 

Multiple Card command error 








• 














39 
3A 


Interaction with call/SM control by USIM, permanent problem 
Bearer Independent Protocol error 






• 


• • 


• 












3B 


Access Technology unable to process command 








• • 
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PROACTIVE COMMAND 1 




CARD POWER 
APDU ON 
CARD 

■30' '31' 


POWER GET 
OFF READ- 
CARD ER 

STATUS 

'32' '33' 


RUN AT LANG 
COMM- NOTIFI 
AND CA 
TION 

'34' '35' 


OPEN CLOSE 

CHANN CHANN 

EL EL 

'40' '41' 


RECEIVE SEND 
DATA DATA 

'42' '43' 


GET SERVIC 
CHANN E 

EL SEARC 
STATUS H 

'44' '45' 


GET DECLA 
SERVIC RE 

E SERVIC 
INFORM E 
ATION 

'46' '47' 






TERMINAL RESPONSE 


00 
01 


Command performed successfully 

Command performed with partial comprehension 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 






02 
03 


Command performed, with missing information 
REFRESH performed with additional EFs read 


• • 


• • 


• • 


• • 


• • 


• 


• 






04 
05 


Command performed succesfully, but requested icon could not 

be displayed 
Command performed, but modified by call control by USIM 








• • 


• • 


• • 


• 






06 
07 


Command performed successfully, limited service 
Command performed with modification 








• 






• 






08 
10 


REFRESH performed but indicated USIM was not active 
Proactive UIGG session terminated by the user 








• 

• • 


• • 


• • 


• 






11 
12 


Backward move in the proactive UIGG session requested by 

the user 
No response from user 




















13 
14 


Help information required by the user 
USSD or SB Transaction terminated by user 




















20 
21 


ME currently unable to process command 
Network currently unable to process command 


• • 


• • 


• • 


• • 
• 


• • 
• 


• • 


• • 






22 
23 


User did not accept the proactive command 

User cleared down call before connection or network release 








• 












24 
25 


Action in contradiction with the current timer state 
Interaction with call control by USIM, temporary problem 








• 












26 
30 


Launch browser generic error 
Command beyond MEs capabilities 


• • 


• • 


• • 


• • 


• • 


• • 


• • 






31 
32 


Command type not understood by ME 
Command data not understood by ME 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 


• • 

• • 






33 

34 


Command number not known by ME 
SS Return Error 


• • 


• • 


• • 


• • 


• • 


• • 


• • 






35 
36 


SMS RPERROR 

Error, required values are missing 


• • 


• • 


• • 


• • 


• • 


• • 


• • 






37 
38 


USSD return error 

Multiple Card command error 


• • 


• • 
















39 
3A 


Interaction with call/SM control by USIM, permanent problem 
Bearer Independent Protocol error 








• • 


• • 


• 


• • 






3B 


Access Technology unable to process command 








• 




• 


• 
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7 ENVELOPE Commands 

7.1 Data download to UICC 
7.1.1 SMS-PP data download 

7.1.1.1 Procedure 

If the service "data download via SMS Point-to-point" is allocated and activated in the UICC Service Table (see 
3G TS 31.101 [13]), then the ME shall follow the procedure below: 

when the ME receives a Short Message with: 

- protocol identifier = SIM data download; and 
data coding scheme = class 2 message; or 

when the ME receives a Short Message with: 

- protocol identifier=ANSI-136 R-DATA (see 3G TS 23.040 [7]); and 

data coding scheme = class 2 message, and the ME chooses not to handle the message ( e.g. MEs not 
supporting EGPRS over TIA/EIA-136 do not need to handle the message). 

- then the ME shall pass the message transparently to the UICC using the ENVELOPE (SMS-PP DOWNLOAD) 
command as defined below; 

the ME shall not display the message, or alert the user of a short message waiting; 

the ME shall wait for an acknowledgement from the UICC; 

if the UICC responds with '90 00', the ME shall acknowledge the receipt of the short message to the network 
using an RP-ACKmessage. The response data from the UICC will be supplied by the ME in the TP-User-Data 
element of the RP-ACK message it will send back to the network (see 3G 23.040 [5] and 3G 24.01 1 [10]). The 
values of protocol identifier and data coding scheme in RP-ACK shall be as in the original message; 

if the UICC responds with '93 00', the ME shall either retry the command or send back an RP-ERROR message 
to the network with the TP-FCS value indicating 'SIM Application Toolkit Busy' (see 3G 23.040 [5]). 

If the UICC responds with '6F XX', the ME shall send back an RP-ERROR message to the network with the TP- 
FCS value indicating "UICC data download error". The values of protocol identifier and data coding scheme in 
RP-ERROR shall be as in the original message; 

NOTE: The preferred way for a USAT application to indicate a Data Download error is by using the specific code 
'62 XX' or '63 XX' as desribed in the following bullet point. 

if the UICC responds with '62 XX' or '63 XX', the ME shall acknowledge the receipt of the short message to the 
network using an RP-ERROR message. The response data from the UICC will be supplied by the ME in the TP- 
User-Data element of the RP-ERROR message it will send back to the network (see 3G 23.040 [5] and 
3G 24.011 [10]). The values of protocol identifier and data coding scheme in RP-ERROR shall be as in the 
original message. The value of the TP-FCS element of the RP-ERROR shall be "SIM data download error". 

If the service "data download via SMS-PP" is not available in the UICC Service Table, and the ME receives a Short 
Message with the protocol identifier = SIM data download and data coding scheme = class 2 message, then the ME 
shall store the message in EF§,y[5 in accordance with 3G TS 31.102 [14]. 

7.1 .1 .2 Structure of ENVELOPE (SMS-PP DOWNLOAD) 

Direction: ME to UICC. 
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The command header is specified in TS 31.101 [13]. 
Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


SMS-PP download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Device identities 


8.7 


M 


Y 


A 


Address 


8.1 





N 


B 


SMS TPDU (SMS-DELIVER) 


8.13 


M 


Y 


C 



Device identities: the ME shall set the device identities to: 

source: Network; 

- destination: UICC. 

Address: The address data object holds the RP_Originating_Address of the Service Centre (TS-Service-Centre- 
Address), as defined in 3G 24.01 1 [10]. 

Response parameters/data. 

It is permissible for the UICC not to provide response data. If the UICC provides response data, the following data is 
returned. 



Byte(s) 


Description 


Length 


1-X(X<128) 


UICC Acknowledgement 


X 



7.1 .2 Cell Broadcast data download 



7.1.2.1 



Procedure 



If the service "data download via SMS-CB" is available in the UICC Service Table or USIM Service Table (see 
TS 31.102 [14]), then the ME shall follow the procedure below: 

when the ME receives a new Cell Broadcast message, the ME shall compare the message identifier of the Cell 
Broadcast message with the message identifiers contained in EF(;^g[^jj-,; 

if the message identifier is found in EF(;^g[^jj-,, the cell broadcast page is passed to the UICC using the 
ENVELOPE (CELL BROADCAST DOWNLOAD) command, defined below. The ME shall not display the 
message; 

if the message identifier of the incoming cell broadcast message is not found in EF(-;g]y[jj-,, then the ME shall 

determine if the message should be displayed, by following the procedures in 3G 23.041 [6] and 
3GTS 31.102 [14]. 

The ME shall identify new cell broadcast pages by their message identifier, serial number and page values. 

7.1 .2.2 Structure of ENVELOPE (CELL BROADCAST DOWNLOAD) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 
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Description 


Subclause 


M/O/C 


Min 


Length 


Cell Broadcast Download tag 


9.1 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Device identities 


8.7 


M 


Y 


A 


Cell Broadcast page 


8.5 


M 


Y 


B 



Device identities: the ME shall set the device identities to: 

source: Network; 

- Destination: UICC. 
Response parameters/data: None for this type of ENVELOPE command. 



7.2 



Menu Selection 



A set of possible menu options can be supplied by the UICC using the proactive command SET UP MENU. If the 
UICC has sent this command, and the user subsequently chooses an option or, the user requests help on it, the ME 
informs the UICC using this procedure. 



7.2.1 



Procedure 



The ME shall follow the procedure below. 

When the ME receives a menu selection from one of the menu items defined by a "SET-UP MENU" command 
issued previously by the UICC, or the user has indicated the need to get help information on one of these menu 
items, then it shall pass the identifier of the selected menu item to the UICC using the ENVELOPE (MENU 
SELECTION) command, as defined below. 

7.2.2 Structure of ENVELOPE (MENU SELECTION) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/O/C 


Min 


Length 


Menu Selection tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Device identities 


8.7 


M 


Y 


A 


Item identifier 


8.10 


M 


Y 


B 


Help request 


8.21 





N 


C 



Device identities: the ME shall set the device identities to: 

source: Keypad; 

destination: UICC. 

Help request: inclusion of this data object depends upon whether the user actually selected the named menu item 
or just requested help information on it. If the user actually selected the menu item, this data object shall not be 
included. If the user indicated the need to get help information on the menu item, this data object shall be 
included. 

Response parameters/data: None for this type of ENVELOPE command. 
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7.3 Call Control and MO SMS control by USIM 

7.3.1 Call Control by USIM 

7.3.1 .1 Procedure for mobile originated calls 

If the service "call control" is available in the USIM Service Table (see TS 31.102 [14]), then the ME shall follow the 
procedure below: 

for all call set-up attempts (even those resulting from a SET UP CALL proactive UICC command, from the 
Bearer Independant Protocol proactive UICC commands where CSD is selected, or those occurring when 
another call is already in progress, and those resulting from automatic redial attempts), the ME shall first pass the 
call set-up details (dialled digits and associated parameters) to the UICC, using the ENVELOPE (CALL 
CONTROL) command defined below. The "Location Information" shall be the current information, even for 
automatic redial attempts. USAT applications should take into account the following exception; 

when the user is dialling "112" or an emergency call code stored in EFecc, for which the ME sets up an 
emergency call instead of passing the call set-up details to the UICC; 

if the UICC responds with '90 00', the ME shall set up the call with the dialled digits and other parameters as sent 
to the UICC; 

if the UICC responds with '93 00', the ME shall not set up the call and may retry the command; 

if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to 
set up the call as proposed, not set up the call, set up a call using the data supplied by the UICC, or instead send a 
supplementary service or USSD operation using the data supplied by the UICC. It is mandatory for the ME to 
perform the call set-up request and the supplementary service or USSD operation in accordance with the data 
from the UICC, if it is within the ME's capabilities to do so. If the UICC requires a call set-up or supplementary 
service or USSD operation that is beyond the ME's capabilities (e.g. the UICC maps a speech call to a data call, 
and the ME does not support data calls), then the ME shall not perform the call set-up request or supplementary 
service or USSD operation at all. It is possible for the UICC to request the ME to set up an emergency call by 
supplying the number " 1 12" as the response data. If the UICC supplies a number stored in EFecc, this shall not 
result in an emergency call. 

In the case where the initial call set-up request results from a proactive command SET UP CALL: 

- if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE 
"interaction with call control by UICC or MO short message control by UICC, action not allowed"; 

if the call set-up request is changed by call control in a supplementary service or USSD operation, and if the 
supplementary service or USSD operation is within the ME's capabilities, then the ME shall send this request to 
the network. The ME shall then send back a TERMINAL RESPONSE to the SET UP CALL command at the 
same time it would have done for the proactive command equivalent to the action requested by call control 
(i.e. SEND SS or SEND USSD). However, in that case, the TERMINAL RESPONSE shall contain the response 
data given in the response to ENVELOPE (CALL CONTROL) and a second Result TLV identical to the one 
given in response to the proactive command equivalent to the action requested by call control (i.e. SEND SS or 
SEND USSD). The mapping between the general result in the first Result TLV and the general result in the 
second Result TLV is given below: 

the general result "command performed, but modified by call control by USIM" shall be given in the first 
Result TLV if the general result of the second Result TLV is 'OX' or 'IX'; 

the general result "interaction with call control by USIM, temporary problem" shall be given in the first 
Result TLV if the general result of the second Result TLV is '2X'; 

the general result "interaction with call control by USIM or MO short message control by USIM, permanent 
problem" shall be given in the first Result TLV if the general result of the second Result TLV is '3X'. 
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if the call set-up request is changed by call control into a supplementary service or USSD operation, and if the 
supplementary service or USSD operation is beyond the ME's capabilities, then the ME shall send back a 
TERMINAL RESPONSE to the SET UP CALL command, without performing the supplementary service or 
USSD operation at all. In that case, the TERMINAL RESPONSE shall contain the response data given in the 
response to ENVELOPE (CALL CONTROL) and a second Result TLV identical to the one given in response to 
the proactive command equivalent to the action requested by call control (i.e. SEND SS or SEND USSD). The 
mapping between the general result in the first Result TLV and the general result in the second Result TLV is 
given below: 

the general result "interaction with call control by USIM or MO short message control by USIM, permanent 
problem" shall be given in the first Result TLV, and the general result "command beyond ME's capabilities" 
shall be given in the second Result TLV. 

If the ME supports the Last Number Dialled service, the ME shall update EFlnd with the call set-up details (digits string 
and associated parameters) corresponding to the initial user request. 

The ME shall then follow the call set-up procedure defined in 3G 24.008 [9] or the supplementary service or USSD 
operation procedure defined in 3G 24.080 [11]. 

7.3.1 .2 Procedure for Supplementary Services and USSD 

If the service "call control" is available in the USIM Service Table (see TS 31.102 [14]), then for all supplementary 
service and USSD operations (including those resulting from a SEND SS or SEND USSD proactive UICC command), 
the ME shall first pass the supplementary service or USSD control string (corresponding to the supplementary service 
or USSD operation and coded as defined in 3G 22.030 [2], even if this SS or USSD operation has been performed via a 
specific menu of the ME) to the UICC, using the ENVELOPE (CALL CONTROL) command defined below. The ME 
shall also pass to the UICC in the ENVELOPE (CALL CONTROL) command the current serving cell. 

The UICC shall respond in the same way as for mobile originated calls. The ME shall interpret the response as follows: 

if the UICC responds with '90 00', the ME shall send the supplementary service or USSD operation with the 
information as sent to the UICC; 

if the UICC responds with '93 00', the ME shall not send the supplementary service or USSD operation and may 
retry the command; 

if the UICC provides response data,then the response data from the UICC shall indicate to the ME whether to 
send the supplementary service or USSD operation as proposed, not send the SS or USSD operation, send the SS 
or USSD operation using the data supplied by the UICC, or instead set up a call using the data supplied by the 
UICC. It is mandatory for the ME to perform the supplementary service or USSD operation or the call set-up 
request in accordance with the data from the UICC, if it is within the ME's capabilities to do so. If the UICC 
requires a call set-up or supplementary service or USSD operation that is beyond the ME's capabilities (e.g. the 
UICC maps a USSD operation to a data call, and the ME does not support data calls), then the ME shall not the 
perform the call set-up request or supplementary service or USSD operation at all. 

In the case where the initial SS or USSD request results from a proactive command SEND SS or SEND USSD: 

- if the call control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE 
("interaction with call control by UICC or MO short message control by UICC, action not allowed"); 

if the SS or USSD request is changed by call control in a call set-up request, then the ME shall set up the call 
using the data given by the UICC, if it is within the ME's capabilities to do so. If the UICC requires a call set-up 
that is beyond the ME's capabilities (e.g. the UICC maps a USSD operation to a data call, and the ME does not 
support data calls), then the ME shall not set up the call at all. The ME shall send back a TERMINAL 
RESPONSE to the initial proactive command at the same time it would have done for the proactive command 
equivalent to the action requested by call control (i.e. SET UP CALL). However, in that case, the TERMINAL 
RESPONSE shall contain the response data given in the response to ENVELOPE (CALL CONTROL) and a 
second Result TLV identical to the one given in response to the proactive command equivalent to the action 
requested by call control (i.e. SET UP CALL). The mapping between the general result in the first Result TLV 
and the general result in the second Result TLV is the same as the one described in subclause 7.3.1.1. 

If the ME supports the Last Number Dialled service, the ME shall update EFlnd with the supplementary service or 
USSD control string corresponding to the initial user request. 
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The ME shall then follow the supplementary service or USSD operation procedure defined in 3G 24.080 [11] or the call 
set-up procedure defined in 3G 24.008 [9]. 

7.3.1 .3 Indication to be given to the user 

The UICC may optionally include an alpha-identifier in the response data to the ENVELOPE (CALL CONTROL) 
message, in order to inform the user at the time the response is received by the ME. The use of this alpha identifier by 
the ME is described below: 

if the UICC responds with "allowed, no modification", then: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the 
user during the call set-up; 

if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), 
this is an indication that the ME should not modify the display corresponding to the initial user request; 

if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what 
is happening; 

if the UICC responds with "not allowed", then: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the reason of 
the barring; 

if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), 
the ME may give information to the user concerning what is happening; 

if the alpha identifier is not provided by the UICC, the ME may give information to the user concerning what 
is happening. 

if the UICC responds with "allowed, with modifications", and the modified request is within the ME's 
capabilities, then: 

if the alpha identifier is provided by the UICC and is not a null data object, the ME shall use it to inform the 
user. The ME shall then not display the destination address or SS string given by the UICC. This is also an 
indication that the ME should not give any other information to the user on the changes made by the UICC to 
the initial user request; 

- if the alpha identifier is provided by the UICC and is a null data object (i.e. length = '00' and no value part), 
this is an indication that the ME should not give any information to the user on the changes made by the 
UICC to the initial user request. The ME shall not display the destination address or SS string given by the 
UICC. The ME should not modify the display corresponding to the initial user request; 

if the alpha identifier is not provided by the UICC, the ME may indicate to the user that the initial user 
request has been changed. 

if the UICC responds with "allowed, with modifications" to a user-initiated request (i.e. a request not initiated by 
a proactive command), and the modified user request is beyond the ME's capabilities, then the ME may give 
information to the user on the modified request and the fact that the modified request is beyond the ME's 
capabilities, optionally using the alpha identifier, if one is provided by the UICC. 

if the UICC responds with "allowed, with modifications" to a request by a proactive command SET UP CALL, 
SEND SS or SEND USSD, and the modified request is beyond the ME's capabilities, then the ME shall not give 
any information to the user on the fact that the modified request is beyond the ME's capabilities, and shall give a 
TERMINAL RESPONSE to the proactive command (i.e. SET UP CALL, SEND SS or SEND USSD) as 
detailed in subclauses 7.3.1.1 and 7.3.1.2. The responsibility to inform the user in this case lies with the UICC 
application which sent the proactive command. 

7.3.1 .4 Interaction with Fixed Dialling Number 

It is permissible for the Fixed Dialling Number service to be enabled (see TS 31.102 [14]) at the same time as Call 
Control is available in the USIM Service Table. 
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If FDN is enabled and Call Control is activated, the ME shall follow this procedure: 

the ME shall check that the number (or the supplementary service control string) entered through the MMI is on 
the FDN list, in accordance with GSM 02.07 [20]; 

if the MMI input does not pass the FDN check, the call (or the supplementary service operation) shall not be 
set-up; 

if the MMI input does pass the FDN check, the ME shall pass the dialled digits (or the supplementary service 
control string) and other parameters to the UICC, using the ENVELOPE (CALL CONTROL) command; 

if the UICC responds with "allowed, no modification", the ME shall set up the call (or the supplementary service 
operation) as proposed; 

if the UICC responds with "not allowed", the ME shall not set up the call (or the supplementary service 
operation); 

if the UICC responds with "allowed with modifications", the ME shall set up the call (or supplementary service 
operation) in accordance with the response from the UICC. If the modifications involve changing the dialled 
digits (or the supplementary service control string), the ME shall not re-check this modified number (or string) 
against the FDN list. 

If the user wishes to enable or disable Fixed Dialling Number, the ME shall follow the procedure in TS 31.102 [14]. 
The state of the Call Control service shall have no effect on this procedure. 

7.3.1 .5 Support of Barred Dialling Number (BDN) service 

The BDN service shall be allocated and activated in the USIM Service Table only if Call Control is also available in the 
USIM Service Table. 

If Barred Dialling Number service is enabled (see TS 31.102 [14]), when receiving the dialled number (or 
supplementary service control string) and other parameters from the ME, the USIM may check this information against 
those stored in EFgQj,^ (examples of comparison methods are given in GSM 02.07 [20]). 

If the UICC responds with "not allowed" (e.g., a match is made against a BDN), the ME shall not set up the call 
(or the supplementary service operation). 

If the UICC responds with "allowed, no modification", the ME shall set up the call (or the supplementary service 
operation) as proposed. 

If the UICC responds with "allowed with modifications", the ME shall set up the call (or the supplementary 
service operation) in accordance with the response from the UICC. If the modifications involve changing the 
dialled number (or the supplementary service control string), the ME shall not re-check this modified number (or 
string) against the FDN list when FDN is enabled. 

If the user wishes to enable or disable Barred Dialling Number, the ME shall follow the procedure in TS 31.102 [14]. 

7.3.1 .6 Structure of ENVELOPE (CALL CONTROL) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 
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Description 


Subclause 


IM/O/C 


Min 


Length 


Call control tag 


9.1 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Device identities 


8.7 


M 


Y 


A 


Address or SS string or USSD string 


8.1, 8.14or 
8.17 


M 


Y 


B 


Capability configuration parameters 1 


8.4 





N 


C 


Subaddress 


8.3 





N 


D 


Location information 


8.19 


M 


N 


E 


Capability configuration parameters 2 


8.4 





N 


F 



Device identities: the ME shall set the device identities to: 



source: 



ME; 



destination: UICC. 

Address or SS string or USSD string: only one data object shall be sent to the UICC: 

for a call set-up, the address data object is used and holds the Called Party Number, as defined in 3G 
24.008 [9], to which the ME is proposing setting up the call; 

for a supplementary service, the SS string data object is used and holds the corresponding supplementary 

service; 

for a USSD operation, the USSD string data object is used and holds the corresponding USSD control string; 

USIM Applications and MEs should take into account that early implementations of USAT use the SS string 
data object for coding of USSD control strings (instead of the USSD string data object). This behaviour is 
only possible for USSD control strings consisting of digits (0-9,*,#). The UICC can identify MEs having this 
early implementation by evaluating the indication "USSD string data object supported in Call Control" in the 
TERMINAL PROFILE. The ME can identify SIMs having this early implementation by evaluating the 
indication "USSD string data object supported in Call Control" in the UICC Service Table. 

Capability configuration parameters: Only used for a call set-up, this contains the Bearer capabilities that the ME 
is proposing to send to the network. The first capability configuration parameters corresponds to the bearer 
capability 1 information element of a mobile originating SETUP message, as defined in 3G 24.008 [9]. The 
second capability configuration parameters correspond to the bearer capability 2 information element of a mobile 
originating SETUP message, as defined in 3G 24.008 [9]. If no capability configuration parameters are present, 
this shall indicate a speech call. 

Subaddress: Only used for a call set-up, this contains the called party subaddress that the ME is proposing to 
send to the network. If one is not present, this shall indicate that the ME is proposing not to send this information 
element to the network. 

Location information: This data object contains the identification (MCC, MNC, LAC, Cell Identity) of the 
current serving cell of the UE. The comprehension required flag of this data object in this command shall be set 
to '0'. 

Response parameters/data. 

It is permissible for the UICC to provide no response data, by responding with SWl / SW2 = '90 00'. If the UICC does 
not provide any response data, then this shall have the same meaning as "allowed, no modification". 
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Description 


Subclause 


IM/O/C 


Min 


Length 


Call control result 


- 


M 


Y 


1 


Length (A+B+C+D+E+F) 


- 


M 


Y 


1 or 2 


Address or SS string or USSD string 


8.1, 8.14or 
8.17 





N 


A 


Capability configuration parameters 1 


8.4 





N 


B 


Subaddress 


8.3 





N 


C 


Alpha identifier 


8.2 





N 


D 


BC repeat indicator 


8.42 


C 


N 


E 


Capability configuration parameters 2 


8.4 





N 


F 



Call control result: 

contents: the command that the UICC gives to the ME concerning whether to allow, bar or modify the 
proposed call (or supplementary service operation); 

Coding: 

'00' = Allowed, no modification; 
- '01 ' = Not allowed; 

'02' = Allowed with modifications. 

- Address or SS string or USSD string: Only one data object may be included if the UICC requests the call (or 
supplementary service or USSD operation) details to be modified: 

for a call set-up, if the address data object is not present, then the ME shall assume the Dialling number is not 
to be modified; 

for a supplementary service, if the SS string data object is not present, then the ME shall assume that SS is 
not to be modified; 

for a USSD operation, if the USSD string data object is not present, then the ME shall assume that the USSD 
operation is not to be modified. 

Capability configuration parameters: Only used for a call set-up, this data object is only required if the USIM 
application requests the call details to be modified. The first capability configuration parameters corresponds to 
the bearer capability 1 information element of a mobile originating SETUP message, as defined in 3G 
24.008 [9]. The second capability configuration parameters corresponds to the bearer capability 2 information 
element of a mobile originating SETUP message, as defined in 3G 24.008 [9]. If the capability configuration 
parameters are not present, then the ME shall assume the parameters are not to be modified. 

Subaddress: Only used for a call set-up, this data object is only required if the USIM application requests the call 
details to be modified. If the subaddress is not present, then the ME shall assume the called party subaddress is 
not to be modified. If the subaddress supplied by the USIM application is a null data object, then the ME shall 
not provide a called party subaddress to the network. A null data object shall have length = '00' and no value 
part. 

Alpha identifier: this data object is only required if the UICC requests a particular indication to be given to the 
user. The handling of this data object by the ME is described in subclause 7.3.1.3. The comprehension required 
flag of this data object shall be set to '0'. 

BC repeat indicator: indicates how the 2 associated bearers shall be interpreted. The two modes to manage the 
bearers are the "alternate way" or "sequential way". The change of bearer occurs on a network event. This BC 
repeat indicator is conditioned to the presence of the second capability configuration parameters and is coded as 
defined in 3G 24.008 [9]. 

It is mandatory for the UICC to provide at least one of the optional data objects if it has set the Call control result to 
"allowed with modifications". 
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7.3.2 MO Short Message Control by USIM 



7.3.2.1 



Description 



If the service "MO Short Message Control" is available in the USIM Service Table (see 31.102 [14]), then the ME shall 
follow the procedure below: 

for all MO short message attempts (even those resulting from a SEND SM proactive UICC command), the ME 
shall first pass the RP_destination_address of the service center and the TP_Destination_Address to the UICC, 
using the ENVELOPE (MO SHORT MESSAGE CONTROL) command defined below. The ME shall also pass 
to the UICC in the ENVELOPE (MO SHORT MESSAGE CONTROL) command the current serving cell; 

if the UICC responds with '90 00', the ME shall send the short message with the addresses unchanged; 

if the UICC responds with '93 00', the ME shall not send the short message and may retry the command; 

if the UICC provides response data, then the response data from the UICC shall indicate to the ME whether to 
send the short message as proposed, not send the short message or send a short message using the data supplied 
by the UICC. It is mandatory for the ME to perform the MO short message request in accordance with the data 
from the UICC. 

The ME shall then follow the MO Short Message procedure defined in 3G 24.01 1 [10]. 

In the case where the initial MO short message request results from a proactive command SEND SHORT MESSAGE, 
if the MO short message control result is "not allowed", the ME shall inform the UICC using TERMINAL RESPONSE, 
"interaction with call control by UICC or MO short message control by UICC, action not allowed". 

7.3.2.2 Structure of ENVELOPE (MO SHORT MESSAGE CONTROL) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


IM/O/C 


Min 


Length 


MO Short Message control tag 


9.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Device identities 


8.7 


M 


Y 


A 


Address data object 1 


8.1 


M 


Y 


B 


Address data object 2 


8.1 


M 


Y 


C 


Location information 


8.19 


M 


Y 


D 



Device identities: the ME shall set the device identities to: 

source: ME; 

destination: UICC. 

Address data object 1: this address data object 1 contains the RP_Destination_Address of the Service Center to 
which the ME is proposing to send the short message. 

Address data object 2: this address data object 2 contains the TP_Destination_Address to which the ME is 
proposing to send the short message. 

- Location information: this data object contains the identification (MCC, MNC, LAC, Cell Identity) of the current 
serving cell of the UE. 

Response parameters/data. 

It is permissible for the UICC to provide no response data, by responding with SWl / SW2 = '90 00'. If the UICC does 
not provide any response data, then this shall have the same meaning as "allowed, no modification". 
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Description 


Subclause 


M/O/C 


Min 


Length 


MO short message control result 


- 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Address data object 1 


8.1 





N 


A 


Address data object 2 


8.1 





N 


B 


Alpha identifier 


8.2 





N 


C 



MO Short Message control result: 

contents: the command that the UICC gives to the ME concerning whether to allow, bar or modify the 
proposed short message; 

coding: 

'00' = Allowed, no modification; 
- 'Or = Not allowed; 

'02' = Allowed with modifications. 

Address data object 1: if the address data object 1 is not present, then the ME shall assume the 
RP_Destination_Address of the Service Center is not to be modified. 

- Address data object 2: if the address data object 2 is not present, then the ME shall assume the 
TP_Destination_Address is not to be modified. 

Alpha identifier: this data object is only required if the UICC requests a particular indication to be given to the 
user. The handling of this data object by the ME is described in subclause 7.3.2.3. 

The UICC shall provide the two optional address data objects if it has set the MO Short Message control result to 
"allowed with modifications". 



7.3.2.3 



Indication to be given to the user 



The UICC may optionally include an alpha-identifier in the response data to the ENVELOPE (MO SHORT MESSAGE 
CONTROL) message, in order to inform the user at the time the response is received by the ME. The use of this alpha 
identifier by the ME is identical to the one described in subclause 7.3.1.3 relative to call control by UICC. 



7.3.2.4 



Interaction with Fixed Dialling Number 



It is permissible for the Fixed Dialling Number service to be enabled (see TS 31.102 [14]) at the same time as MO Short 
Message Control is available (in the USIM Service Table). If FDN is enabled, the ME shall follow the procedure for 
Call Control (see subclause 7.3.1.4), where the number in the procedure refers to both the SMS destination address and 
the SMSC address. 

7.4 Timer Expiration 

7.4.1 Description 

When a timer previously started by a TIMER MANAGEMENT proactive command expires, the ME shall pass the 
identifier of the timer that has expired and its value using the ENVELOPE (TIMER EXPIRATION) command, as 
defined below. 

If the UICC is busy and returns status '93 00', the ME shall retry until the command is accepted. 

NOTE: In order to avoid retrying periodically, the ME could retry after a TERMINAL RESPONSE processed by 
the UICC with status '90 00'. 

7.4.2 Structure of ENVELOPE (TIIVIER EXPIRATION) 

Direction: ME to UICC. 
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The command header is specified in TS 31.101 [13]. 
Command parameters/data. 



Description 


Subclause 


M/O/C 


Min 


Length 


Timer Expiration tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Device identities 


8.7 


M 


Y 


A 


Timer identifier 


8.37 


M 


Y 


B 


Timer value 


8.38 


M 


Y 


C 



Device identities: the ME shall set the device identities to: 

- Source: ME; 

- Destination: UICC. 

Timer identifier: identifier of the timer that has expired. 

Timer value: difference between the time when this command is issued and the time when the timer was initially 
started. This should be as close as possible to the value of the timer given in the initial TIMER MANAGEMENT 
command. 

Response parameters/data: 



7.5 



Event download 



A set of events for the ME to monitor can be supplied by the UICC using the proactive command SET UP EVENT 
LIST. If the UICC has sent this command, and an event which is part of the list subsequently occurs, the ME informs 
the UICC using the procedure below, relevant for that event. 

Processing within the ME resulting from this event shall proceed as normal, independent of sending the ENVELOPE 
command to the UICC. 

Where events occur while the UlCC-ME interface is already busy, the ME shall queue events and send event download 
messages to the UICC in the order in which they occurred. 



7.5.1 



MT call event 



7.5.1.1 



Procedure 



If the MT call event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the ME receives an incoming SETUP message, the ME shall inform the UICC that this 
has occurred, by using the ENVELOPE (EVENT DOWNLOAD - MT call) command as defined below. 

7.5.1 .2 Structure of ENVELOPE (EVENT DOWNLOAD - MT call) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 
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Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Transaction identifier 


8.28 


M 


Y 


C 


Address 


8.1 


C 


N 


D 


Subaddress 


8.3 


c 


N 


E 



- Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

- MX call. 

Device identities: the ME shall set the device identities to: 

source: Network; 

destination: UICC. 

Transaction identifier: the transaction identifier data object shall contain one transaction identifier, and this shall 
be the Transaction Identifier in the SETUP message from the network. 

Address: The address data object holds the Calling Party BCD number as received by the ME in the SETUP 
message. If the Calling Party BCD number is included in the SETUP message, the ME shall include the Address 
object, otherwise the ME shall not include the Address object. 

Subaddress: The Subaddress data object holds the Calling Party Subaddress as received by the ME in the SETUP 
message. If the Calling Party Subaddress is included in the SETUP message, the ME shall include the 
Subaddress object, otherwise the ME shall not include the Subaddress object. 

Response parameters/data: 

none. 

7.5.2 Call connected event 



7.5.2.1 



Procedure 



If the call connected event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the ME receives an incoming CONNECT message (in the case of an MO call), or when 
the ME sends an outgoing CONNECT message (in the case of an MT call), the ME shall inform the UICC that this has 
occurred, by using the ENVELOPE (EVENT DOWNLOAD - call connected) command as defined below. 

In the case of a call initiated through a SET UP CALL proactive command while the call connected event is part of the 
current event list, the ME shall send both the TERMINAL RESPONSE related to the proactive command, and the 
EVENT DOWNLOAD command, in the order TERMINAL RESPONSE first, ENVELOPE(EVENT DOWNLOAD - 
call connected) second. 

7.5.2.2 Structure of ENVELOPE (EVENT DOWNLOAD - call connected) 

Direction: ME to UICC. 

The command header is specified in TS 3L101 [13]. 
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Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Transaction identifier 


8.28 


M 


Y 


C 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

call connected. 

Device identities: 

in the case of connecting at the near end (an MX call), the ME shall set the device identities to: 

source: ME; 

destination: UICC. 

in the case of connecting at the far end (an MO call), the ME shall set the device identities to: 

source: Network; 

destination: UICC. 

Transaction identifier: the transaction identifier data object shall contain one transaction identifier, and this shall 
be the Transaction Identifier in the CONNECT message. 

Response parameters/data: 

none. 



7.5.3 Call disconnected event 



7.5.3.1 



Procedure 



If the call disconnected event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then if the ME is not in the CC UO (NULL) state (i.e. has sent or received a SETUP message, see 
3G TS 24.008 [9]), and in this state disconnects a call, the ME shall inform the UICC that this has occurred, by using 
the ENVELOPE (EVENT DOWNLOAD - call disconnected) command as defined below. This can happen as the result 
of the ME sending or receiving a DISCONNECT, RELEASE, or RELEASE COMPLETE message, or as the result of a 
radio link failure; if more than one of these occur within the same call, the ENVELOPE command shall be sent on the 
first occurrence. 

If the ME initiates the disconnection, or in the case of radio link failure, this is considered a "near end" disconnection, 
whereas a "far end" disconnection is defined as when the network initiates the disconnection. The ME shall set the 
Device Identities accordingly. 

7.5.3.2 Structure of ENVELOPE (EVENT DOWNLOAD - Call disconnected) 

Direction: ME to UICC. 

The command header is specified in TS 3L101 [13]. 
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Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Transaction identifier 


8.28 


M 


Y 


C 


Cause 


8.26 





N 


D 



- Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

call disconnected. 

Device identities: 

in the case of "near end" disconnection, the ME shall set the device identities to: 

source: ME; 

- destination: UICC. 

in the case of "far end" disconnection, the ME shall set the device identities to: 

source: Network; 

destination: UICC. 

Transaction identifier: the transaction identifier data object shall contain a list of the transaction identifiers for 
each of the calls being disconnected. 

Cause: the cause shall reflect the CC-Cause information element sent or received in the DISCONNECT, 
RELEASE or RELEASE COMPLETE message (see TS 3G 24.008 [9]) triggering the ENVELOPE command. If 
the Cause information element was not present in the message, or the Cause data object shall not be included. In 
the case of a radio link timeout, the Cause data object shall be included, with a value part of zero length. 

Response parameters/data: 

none. 



7.5.4 Location status event 



7.5.4.1 



Procedure 



If the location status event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the ME enters the MM-IDLE state (see TS 3G 24.008 [9]) with the result that either the 
Location status or Location information has been changed or updated, the ME shall inform the UICC that this has 
occurred, by using the ENVELOPE (EVENT DOWNLOAD - location status) command as defined below. 

7.5.4.2 Structure of ENVELOPE (EVENT DOWNLOAD - Location status) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 
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Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Location status 


8.27 


M 


Y 


C 


Location information 


8.19 


C 


N 


D 



- Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

location status. 
Device identities: the ME shall set the device identities to: 

source: ME; 

- destination: UICC. 

Location status: This object shall contain the current service state of the UE. 

Location information: This object shall only be included if the Location status object indicates Normal Service. 
This object shall contain the details of the network, location area and cell that have been selected. 

Response parameters/data: 

none. 



7.5.5 User activity event 



7.5.5.1 



Procedure 



If the user activity event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then the ME shall follow the procedure below: 

when the ME next detects some user activity (e.g. a key-press, removal of key-lock), the ME shall inform the 
UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - user activity) command as 
defined below; 

as a result of sending this command to the UICC, the ME shall remove the user activity event from its current 
event list. This is in order for the ME to report this event only once after the event has been requested by the 
UICC. 

7.5.5.2 Structure of ENVELOPE (EVENT DOWNLOAD - User activity) 

Direction: ME to UICC. 

The command header is specified in 3G TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 
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- Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

user activity. 
Device identities: the ME shall set the device identities to: 

source: ME; 

- destination: UICC. 
Response parameters/data: 
none. 



7.5.6 Idle screen available event 



7.5.6.1 



Procedure 



If the idle screen available event is part of the current event list (as set up by the last SET UP EVENT LIST command, 
see subclause 6.4.16), then the ME shall follow the procedure below: 

when the ME next enters a state where it would accept rather than reject a DISPLAY TEXT command of normal 
priority, the ME shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD 
- idle screen available) command as defined below; 

as a result of sending this command to the UICC, the ME shall remove the idle screen available event from its 
current event list. This is in order for the ME to report this event only once after the event has been requested by 
the UICC. 

7.5.6.2 Structure of ENVELOPE (EVENT DOWNLOAD - Idle screen available) 

Direction: ME to UICC. 

The command header is specified in TS 3L101 [13]. 

Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

idle screen available. 
Device identities: the ME shall set the device identities to: 

source: Display; 

destination: UICC. 
Response parameters/data: 
none. 

7.5.7 Card reader status event 

The following subclauses under 7.5.7 apply only if class "a" is supported. 
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7.5.7.1 



Procedure 



If the card reader status event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the ME detects one of the following changes: 

a card reader becomes available or unavailable (e.g. a removable card reader is attached); or 

a card is inserted or removed. 

The ME shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - card reader 
status) command as defined below. 

7.5.7.2 Structure of ENVELOPE (EVENT DOWNLOAD - card reader status) 

Direction: ME to UICC. 

The command header is specified in TS 3L101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Card reader status 


8.33 


M 


Y 


C 



- Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

card reader status. 

Device identities: the ME shall set the device identities to: 

source: ME; 

destination: UICC. 

Card reader status: the card reader status data object shall contain the identifier and status flags for the card 
reader that has generated the event. 

Response parameters/data: None for this type of ENVELOPE command. 



7.5.8 Language selection event 



7.5.8.1 



Procedure 



If the language selection event is part of the event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the ME changes the currently used language, the ME shall inform the UICC that this has 
occurred, by using the ENVELOPE (EVENT DOWNLOAD - language selection) command as defined below. 

7.5.8.2 Structure of ENVELOPE (language selection) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 
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Command parameters/data. 



Description 


Subclause 


IW/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Language 


8.45 


M 


Y 


C 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

language selection. 
Device identities: the ME shall set the device identities to: 

source: ME; 

- destination: UICC. 

Language: This object shall contain the currently used language of the ME. 
Response parameters/data: None for this type of ENVELOPE command. 

7.5.9 Browser Termination event 



7.5.9.1 



Procedure 



If the browser termination event is part of the event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the browser is terminated either by the user action or by an error, the ME shall inform the 
UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - browser termination) command as 
defined below. 

7.5.9.2 Structure of ENVELOPE (browser termination) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/0 


lUlin 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Browser termination cause 


8.51 


M 


Y 


C 



- Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

- browser termination. 

Device identities: the ME shall set the device identities to: 
source: ME; 

- destination: UICC. 

Browser termination cause: This object shall contain the browser termination cause. 
Response parameters/data: None for this type of ENVELOPE command. 
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7.5.1 Data available event 

The following subclauses apply only if class "e" is supported. 



7.5.10.1 



Procedure 



If the Data available event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4. 16), then, only if the targeted channel buffer is empty when new data arrives in it, the ME shall inform the 
UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - Data available) command as defined 
below. 

7.5.1 0.2 Structure of ENVELOPE (EVENT DOWNLOAD - Data available) 

Direction: ME to UICC. 

The command header is specified in TS 3L101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/0 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Channel status 


8.56 


M 


Y 


C 


Channel data length 


8.54 


M 


Y 


D 



Event list: the Event list data object shall contain only one event (value part of length 1 byte), and ME shall set 
the event to: 

data available. 
Device identities: the ME shall set the device identities to: 

source: ME; 

- destination: UICC. 

Channel status: this data object shall contain the status and identifier of the channel on which the event occurred. 

Channel data length: this data object shall contain the number of bytes received, eg available in the channel 
buffer. If more than 255 bytes are available, 'FF' is used. 

Response parameters/data: None for this type of ENVELOPE command. 

7.5.1 1 Channel status event 

The following subclauses apply only if class "e" is supported. 

7.5.11.1 Procedure 

If the Channel status event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then, when the ME detects one of the following changes: 

a link is error; or 

a link is established; or 

any other error. 

The ME shall inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - Channel 
status) command as defined below. 
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7.5.1 1 .2 structure of ENVELOPE (EVENT DOWNLOAD - Channel status) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/0 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Channel status 


8.56 


M 


Y 


C 



- Event list: the Event list data object shall contain only one event (value part of length 1 byte), and ME shall set 
the event to: 

channel status. 
Device identities: the ME shall set the device identities to: 

source: ME; 

destination: UICC. 
Channel status: this data object shall contain the status and identifier of the channel on which the event occurred. 
Response parameters/data: None for this type of ENVELOPE command. 



7.5.12 Access Technology Change Event 



7.5.12.1 



Procedure 



If the Access Tehnology Change event is part of the current event list (as set up by the last SET UP EVENT LIST 
command, see subclause 6.4.16), then, when the ME detects a change in its current access technology the ME shall 
inform the UICC that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - Access Technology 
Change) command as defined below. 

7.5.1 2.2 Structure of ENVELOPE (EVENT DOWNLOAD - Access Technology 
Change) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/0 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Access Technology 


8.61 


M 


Y 


C 



Event list: the Event list data object shall contain only one event (value part of length 1 byte), and ME shall set 
the event to: 

Access Technology Change 

Device identities: the ME shall set the device identities to: 
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source: ME; 

- destination: UICC. 

Access Technology: this data object shall contain the current access technology that the ME is using 
Response parameters/data: None for this type of ENVELOPE command. 

7.5.1 3 Display parameters changed event 



7.5.13.1 



Procedure 



If the display parameters changed event is part of the current event list (as set up by the last SET UP EVENT LIST 
command, see section 6.4.16), then when the screen of the ME is resized, the ME shall inform the UICC that this has 
occured, by using the ENVELOPE (EVENT DOWNLOAD - Display parameters changed ) command as defined 
below. 

7.5.1 3.2 Structure of ENVELOPE (EVENT DOWNLOAD - Display parameters 
changed) 

Direction: ME to UICC. 

The command header is specified in TS 31.101 [13]. 

Command parameters/data. 



Description 


Subclause 


M/0 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Display Parameters 


8.62 


M 


Y 


C 



Event list: the Event list data object shall contain only one event (value part of length 1 byte), and ME shall set 
the event to: 

- Display parameters changed 

Device identities: the ME shall set the device identities to: 

source: ME; 

destination: UICC. 
Display parameters changed: this data object shall contain the current ME's screen parameters 
Response parameters/data: None for this type of ENVELOPE command. 

7.5.14 Local Connection event 



7.5.14.1 



Procedure 



If the Local Connection event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
subclause 6.4.16), then when the ME receives an incoming connection request on a local bearer using a service 
previously declared by the UICC, the ME shall inform the UICC that it has occurred, by using the ENVELOPE 
(EVENT DOWNLOAD - Local Connection) command as defined below. The ME shall then wait for an OPEN 
CHANNEL with the parameters given in the event before proceeding with the local connection establishment. 

7.5.1 4.2 Structure of ENVELOPE (EVENT DOWNLOAD - Local Connection) 

Direction: ME to UICC. 
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The command header is specified in TS 31.101 [13]. 
Command parameters/data. 



Description 


Subclause 


M/O/C 


Min 


Length 


Event download tag 


9.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Event list 


8.25 


M 


Y 


A 


Device identities 


8.7 


M 


Y 


B 


Service Record 


8.63 


M 


Y 


D 


Remote Entity Address 


8.x 





N 


C 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the 
event to: 

- Local connection. 

Device identities: the ME shall set the device identities to: 

source: Network; 

destination: UICC. 

Service Record: this data object shall contain the service record of the service being connected by a remote 
device. If the ME provides a Service Record different from '00', the UICC shall ignore it. 

Response parameters/data: 

none. 



8 SIMPLE-TLV data objects 



This clause specifies the coding of the SIMPLE-TLV data objects, which are contained in a BER-TLV data object. 
S1MPLE-TL"V data objects may be transferred across the interface in either direction. A SIMPLE-TLV data object 
consists of a tag of length one byte, a length indicator, which gives the number of bytes in the value field, and a value 
part of variable length, whose contents, meaning and coding are given below. 

Tag codings are given in subclause 9.3 for all SIMPLE-TLV data objects. 

'00' and 'FF' are never used as tag values for SIMPLE-TLVs. This is in alignment with ISO/IEC 7816-6 [18]. Padding 
characters are not allowed. 

For some of the SIMPLE-TLV data objects described, the length field shall be coded on 1 or 2 bytes (Y value) 
according to annex C, depending on the value of byte 1 . 

All bits and bytes indicated as RFU within all SIMPLE-TLV data objects shall be respectively set to and '00' by the 
sending entity. 

The handling of reserved values and RFU bits or bytes within all SIMPLE-TLV data objects at the receiving entity is 
described in subclause 6.10. 



8.1 



Address 



Byte(s) 


Description 


Length 


1 


Address tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3 


TON and NPI 


1 


(Y-1)+4to 
(Y-1)+X+2 


Dialling number string 


X-1 



TON/NPI is coded as for EF^dn. 
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Dialling number string is coded as for EF^pj^, and may include DTMF separators and DTMF digits, which the ME 
shall send in the same way as for EF^^js^ but without locally generating audible DTMF tones to the user. 

See TS 31.102 [14] for the coding of all EFs. 



8.2 Alpha identifier 



Byte(s) 


Description 


Length 


1 


Alpha identifier tag 


1 


2to(Y-1)+2 


Length (X) 


Y1 


{Y-1)+3to 
(Y-1)+X+2 


Alpha identifier 


X 



The alpha identifier is coded as for EF^pj^. 
See TS 31.102 [14] for the coding of all EFs. 



8.3 



Subaddress 



Byte(s) 


Description 


Length 


1 


Subaddress tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


{Y-1)+3to 
(Y-1)+X+2 


Subaddress 


X 



Subaddress contains information as defined for this purpose in 3G 24.008 [9] (calling party subaddress or called party 
subaddress). All information defined in 3G 24.008 shall be given in the value part of the data object, except the 
information element identifier and the length of subaddress contents (which is given by the length part of the data 
object). 

8.4 Capability configuration parameters 



Byte(s) 


Description 


Length 


1 


Capability configuration parameters tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1)+X+2 


Capability configuration parameters 


X 



Capability configuration parameters are coded as for EFccp- If it is being provided by the UICC, the UICC shall supply 
all information required to complete the Bearer Capability Information Element in the Call Set-up message (see 
3G 24.008 [9]). Any unused bytes at the end of the value part shall be coded 'FF'. 

See TS 31.102 [14] for the coding of all EFs. 

NOTE: The second byte of this TLV contains the Length of the TLV and the third byte contains the Length of the 
bearer capability contents, followed by the actual contents. 



8.5 Cell Broadcast Page 



Byte(s) 


Description 


Length 


1 


Cell Broadcast page tag 


1 


2 


Length = '58' (88 decimal) 


1 


3-90 


Cell Broadcast page 


88 



The Cell Broadcast page is formatted in the same way as described in 3G 23.041 [6]. 



£75/ 



3GPP TS 31.111 version 4.3.0 Release 4 



98 



ETSI TS 131 111 V4.3.0 (2001-06) 



8.6 



Command details 



Byte(s) 


Description 


Length 


1 


Command details tag 




2 


Length = '03' 




3 


Command number 




4 


Type of command 




5 


Command Qualifier 





Command number 

for contents and coding, see subclause 6.5.1. 

Type of command: 

contents: The Type of Command specifies the required interpretation of the data objects which follow, and 
the required ME procedure; 

coding: 

see subclause 9.4; 

the ME shall respond to reserved values (i.e. values not listed) with the result "Command type not 
understood". 

Command Qualifier: 

contents: Qualifiers specific to the command; 

coding: 

- REFRESH: 

'00' = USIM Initialization and Full File Change Notification; 

'01' = File Change Notification; 

'02' = USIM Initialization and File Change Notification; 

- '03' = USIM Initialization; 

- '04' = UICC Reset; 

- '05' = USIM Application Reset; 
'06' = 3G Session Reset; 

'07' to 'FF' = reserved values. 

- MORE TIME: 

- this byte is RFU. 

- POLL INTERVAL: 

- this byte is RFU. 

- POLLING OFF: 

- this byte is RFU. 

- SET UP CALL: 

'00' = set up call, but only if not currently busy on another call; 

'01' = set up call, but only if not currently busy on another call, with redial; 
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'02' = set up call, putting all other calls (if any) on hold; 

'03' = set up call, putting all other calls (if any) on hold, with redial; 

'04' = set up call, disconnecting all other calls (if any); 

'05' = set up call, disconnecting all other calls (if any), with redial; 

'06' to 'FF' = reserved values. 

- SEND DTMF: 

- this byte is RFU. 

- SET UP EVENT LIST: 

- this byte is RFU. 

- SEND SS: 

- this byte is RFU. 

- SEND USSD: 

- this byte is RFU. 

- SEND SHORT MESSAGE: 

- bit 1 : = packing not required; 

1 = SMS packing by the ME required. 

- bits 2-8: =0 RFU. 

- PLAY TONE: 

- this byte is RFU. 

- DISPLAY TEXT: 

- bit 1 : = normal priority; 

1 = high priority. 

- bits 2-7: = RFU. 

- bit 8: = clear message after a delay; 

1 = wait for user to clear message. 

- GET INKEY: 

- bit 1 : = digits (0-9, *, # and +) only; 

1 = alphabet set. 

- bit 2: = SMS default alphabet; 

1 = UCS2 alphabet. 

- bit 3: = character sets defined by bit 1 and bit 2 are enabled; 

1 = character sets defined by bit 1 and bit 2 are disabled and the "Yes/No" response is 
requested. 

bit 4: = user response shall be displayed. The ME may allow alteration and/or confirmation; 

1 = an immediate digit response (0-9, * and #) is requested. 
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- bits 5-7: = RFU. 

- bit 8: = no help information available; 

1 = help information available. 

- GET INPUT: 

- bitl: = digits (0-9, *,#, and +) only; 

1 = alphabet set. 

- bit 2: = SMS default alphabet; 

1 = UCS2 alphabet. 

- bit 3: = ME may echo user input on the display; 

1 = user input shall not be revealed in any way (see note). 

- bit 4: = user input to be in unpacked format; 

1 = user input to be in SMS packed format. 

- bits 5 to 7: =RFU. 

- bit 8: = no help information available; 

1 = help information available. 

NOTE: Where user input is not to be revealed, the ME may provide an indication of key entries, such as by 
displaying "*"s. See subclause 6.4.3 for more information on the character set available in this mode. 

- SELECT ITEM: 

- bit 1 : = presentation type is not specified; 

1 = presentation type is specified in bit 2. 

- bit 2: = presentation as a choice of data values if bit 1 = '1'; 

1 = presentation as a choice of navigation options if bit 1 is '1'. 

- bit 3: = no selection preference; 

1 = selection using soft key preferred. 

- bits 4 to 7: = RFU. 

- bit 8: = no help information available; 

1 = help information available. 

- SET UP MENU: 

- bitl: = no selection preference; 

1 = selection using soft key preferred. 

- bits 2 to 7: =RFU. 

- bit 8: = no help information available; 

1 = help information available. 

- PROVIDE LOCAL INFORMATION: 

- '00' = Location Information (MCC, MNC, LAC and Cell Identity); 
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- '01' = IMEIoftheME; 

'02' = Network Measurement results; 
'03' = Date, time and time zone; 
'04' = Language setting; 
'05' = Timing Advance; 
'06' = Access Technology; 
'07' to 'FF' = Reserved. 

- SET UP IDLE MODE TEXT: 

- this byte is RFU. 

- PERFORM CARD APDU: 

- this byte is RFU. 

- POWER OFF CARD: 

- this byte is RFU. 

- POWER ON CARD: 

- this byte is RFU. 

- GET READER STATUS: 

'00' = Card reader status; 
'01' = Card reader identifier; 
'02' to 'FF' = Reserved. 

- TIMER MANAGEMENT: 

- bits 1 to 2: 00 = start; 

01 = deactivate; 

10 = get current value; 

1 1 = RFU. 

- bits 3 to 8: RFU. 

- RUN AT COMMAND: 

- this byte is RFU. 

- LANGUAGE NOTIFICATION: 

- bit 1 : = non-specific language notification; 

1 = specific language notification. 

- bits 2 to 8: = RFU. 

- LAUNCH BROWSER: 

'00' = launch browser if not already launched; 

'01 ' = not used; 

'02' = use the existing browser (the browser shall not use the active existing secured session); 
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'03' = close the existing browser session and launch new browser session; 
'04' = not used; 

- '05' to 'FF' = RFU. 

- OPEN CHANNEL: 

- bit 1 : = On demand link establishment; 

1 = Immediate link establishment. 

- bits 2 to 8: = RFU. 

- CLOSE CHANNEL: 

- this byte is RFU. 

- RECEIVE DATA: 

- this byte is RFU. 

- SEND DATA: 

- bit 1 : = store data in Tx buffer; 

1 = Send data immediately. 

- bits 2 to 8: = RFU. 

- GET CHANNEL STATUS: 

- this byte is RFU. 

- SERVICE SEARCH (if class "f" is supported) 

- this byte is RFU. 

- GET SERVICE INFORMATION (if class "f" is supported) 

- this byte is RFU. 

- DECLARE SERVICE (if class "f" is supported) 

- bitl: = add a new service to the ME service database 

1 = delete a service from the ME service database 

- bit 2 to 8 RFU 

The ME shall respond to reserved values with the result "Command type not understood". 



8.7 



Device identities 



Byte(s) 


Description 


Length 


1 


Device identities tag 


1 


2 


Length = '02' 


1 


3 


Source device identity 


1 


4 


Destination device identity 


1 



Source device identity: 

contents: the source device for information held in the data objects which follow. 
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Destination device identity: 

contents: the destination device for information held in the data objects which follow; 

NOTE: Only some combinations of Type of Command, Data Download type and Device identities are allowed. 
These are defined in clause 10. 

coding: both Source and Destination device identities are coded as follows: 

- '01' = Keypad; 
'02' = Display; 
'03' = Earpiece; 

'10' to '17' = Additional Card Reader x (0 to 7). Value assigned by ME; 
'21' to '27' = Channel x (1 to 7). Value assigned by ME; 

- '81' = UICC; 

- '82' = ME; 

- '83' = Network; 

All other values are reserved. 



8.8 



Duration 



Byte(s) 


Description 


Length 


1 


Duration tag 


1 


2 


Length = '02' 


1 


3 


Time unit 


1 


4 


Time interval 


1 



Time unit: 

contents: time unit used; minutes, seconds or tenths of seconds; 
coding: 

- '00' Minutes; 
'Or Seconds; 

'02' Tenths of seconds; 

- All other values are reserved. 
Time interval: 

contents: the length of time required, expressed in units; 

coding: The time interval is coded in integer multiples of the time unit used. The range is from 1 unit to 
255 units. The encoding is: 

'00': reserved; 

- '01': 1 unit; 
'02': 2 units; 

'FF': 255 units. 
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8.9 



Item 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3 


Identifier of item 


1 


(Y-1)+4to 
(Y-1)+X+2 


Text string of item 


X-1 



The identifier is a single byte between '01' and 'FF'. Each item shall have a unique identifier within an Item list. 

The text string is coded in the same way as the alpha identifier for EF^y-jj,^. Any unused bytes at the end of the value part 
shall be coded 'FF'. 



8.10 Item identifier 



Byte(s) 


Description 


Length 


1 


Item identifier tag 


1 


2 


Length = '01' 


1 


3 


Identifier of item chosen 


1 



The identifier is a single byte between '01' and 'FF', exactly the same as for the Item data object. A null item identifier is 
coded '00'. 



8.11 Response length 



Byte(s) 


Description 


Length 


1 


Response length tag 


1 


2 


Length = '02' 


1 


3 


Minimum length of response 


1 


4 


Maximum length of response 


1 



The range of length is between '00' and 'FF'. A minimum length coding of '00' indicates that there is no minimum length 
requirement; a maximum length coding of 'FF' indicates that there is no maximum length requirement. If a fixed length 
is required the minimum and maximum values are identical. 

8.12 Result 



Byte(s) 


Description 


Length 


1 


Result tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


{Y-1)+3 


General result 


1 


(Y-1)+4to 
(Y-1)+X+2 


Additional information on result 


X-1 



General result: 

- contents: General result specifies the result and indicates appropriate UICC action; 
coding: 

'00' = Command performed successfully; 

'01' = Command performed with partial comprehension; 

'02' = Command performed, with missing information; 
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'03' = REFRESH performed with additional EFs read; 

'04' = Command performed successfully, but requested icon could not be displayed; 

'05' = Command performed, but modified by call control by USIM; 

'06' = Command performed successfully, limited service; 

'07' = Command performed with modification; 

'08' = REFRESH performed but indicated USIM was not active; 

'10' = Proactive UICC session terminated by the user; 

'11' = Backward move in the proactive UICC session requested by the user; 

'12' = No response from user; 

'13' = Help information required by the user; 

'14' = USSD or SS transaction terminated by the user. 

- results 'OX' and 'IX' indicate that the command has been performed: 

'20' = ME currently unable to process command; 
'21' = Network currently unable to process command; 
'22' = User did not accept the proactive command; 
'23' = User cleared down call before connection or network release; 
- '24' = Action in contradiction with the current timer state; 

'25' = Interaction with call control by USIM, temporary problem. 
'26' = Launch browser generic error code. 

- results '2X' indicate to the UICC that it may be worth re-trying the command at a later opportunity: 

'30' = Command beyond ME's capabilities; 
'31' = Command type not understood by ME; 
'32' = Command data not understood by ME; 
'33' = Command number not known by ME; 

- '34' = SS Return Error; 

- '35' = SMS RP-ERROR; 

'36' = Error, required values are missing; 

- '37' = USSD Return Error; 

'38' = MultipleCard commands error; 

'39' = Interaction with call control by USIM or MO short message control by USIM, permanent problem; 

'3 A' = Bearer Independent Protocol error; 

'3B' = Access Technology unable to process command. 

Results '3X' indicate that it is not worth the UICC re-trying with an identical command, as it will only get the same 
response. However, the decision to retry lies with the application. 

The application should avoid a rapid sequence of repeated retried commands as this may be detrimental to ME 
performance. 
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All other values are reserved. 

Additional information. 

Contents: For the general result "Command performed successfully", some proactive commands require 
additional information in the command result. This is defined in the subclauses below. For the general results 
'20', '21', '26', '34', '35', '37', '38', '39' and '3A', it is mandatory for the ME to provide a specific cause value as 
additional information, as defined in the subclauses below. For the other general results, the ME may optionally 
supply additional information. If additional information is not supplied, then the length of the value part of the 
data object need only contain the general result. 

8.12.1 Additional information for SEND SS 

When the ME issues a successful COMMAND RESULT for a SEND SS proactive command, it shall also include the 
Operation Code and Parameters included in the Return Result component from the network, as additional information. 

The first byte of the additional information shall be the SS Return Result Operation code, as defined in 3G 24.080 [11]. 

The rest of the additional information shall be the SS Return Result Parameters, as defined in 3G 24.080 [11]. 

8.1 2.2 Additional information for ME problem 

For the general result "ME currently unable to process command", it is mandatory for the ME to provide additional 
information, the first byte of which to be as defined below: 

'00' = No specific cause can be given; 

'01 ' = Screen is busy; 

'02' = ME currently busy on call; 

'03' = ME currently busy on SS transaction; 

'04' = No service; 

'05' = Access control class bar; 

'06' = Radio resource not granted; 

'07' = Not in speech call; 

'08' = ME currently busy on USSD transaction; 

- '09' = ME currently busy on SEND DTMF command; 

- 'OA' = No USIM active. 

All other values shall be interpreted by the UICC as 'OO'.The coding '00' shall only be used by the ME if no others apply. 

8.12.3 Additional information for network problem 

For the general result "network currently unable to process command", it is mandatory for the ME to provide additional 
information. The first byte shall be the cause value of the Cause information element returned by the network (as 
defined in 3G 24.008 [9]). Bit 8 shall be set to '1'. One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the UICC as '00'. The coding '00' shall only be used by the ME if no others 
apply. 
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8.1 2.4 Additional information for SS problem 

For the general result "SS Return Error", it is mandatory for the ME to provide additional information. The first byte 
shall be the error value given in the Facility (Return result) information element returned by the network (as defined in 
3G 24.080 [11]). One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the UICC as '00'. The coding '00' shall only be used by the ME if no others 
apply. 

8.1 2.5 Additional information for SMS problem 

For the general result "SMS RP-ERROR", it is mandatory for the ME to provide additional information. The first byte 
shall be the cause value given in the RP-Cause element of the RP-ERROR message returned by the network (as defined 
in 3G 24.01 1 [10]), with bit 8 = 0. One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the UICC as '00'. Specific cause '00' shall only be used by the ME if no others 
apply. 

8.12.6 Not used 

8.12.7 Additional information for USSD problem 

For the general result "USSD Return Error", the ME shall provide additional information. The first byte shall be the 
error value given in the Facility (Return result) information element returned by the network (as defined in 
3G 24.080 [11]). One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the UICC as '00'. 

The coding '00' shall only be used by the ME if no others apply. 

8.1 2.8 Additional information for interaction with call control or MO SM 
control 

For the general result "interaction with call control by USIM or MO short message control by USIM, permanent 
problem", it is mandatory for the ME to provide additional information, the first byte of which to be as defined below: 

'00' = No specific cause can be given; 

'01 ' = Action not allowed; 

'02' = The type of request has changed. 

All other values shall be interpreted by the UICC as '00'. The coding '00' shall only be used by the ME if no others 
apply. 

8.1 2.9 Additional information for MultipleCard commands 

This subclause applies only if class "a" is supported. 

For the general result "MultipleCard commands error", it is mandatory for the ME to provide additional information, the 
first byte of which is defined below: 

'00' = No specific cause can be given; 

'01' = Card reader removed or not present; 
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'02' = Card removed or not present; 
'03' = Card reader busy; 
'04' = Card powered off; 

- '05' = C-APDU format error; 

- '06' = Mute card; 

'07' = Transmission error; 

'08' = Protocol not supported; 

'09' = Specified reader not valid. 
All other values shall be interpreted by the UICC as '00'. 
The coding '00' shall only be used by the ME if no others apply. 

8.12.10 Additional information for Launcli Browser problem 

For the general result "launch browser generic error code", it is mandatory for the ME to provide additional information, 
the first byte of which to be as defined below: 

'00' = No specific cause can be given; 

'01' = Bearer unavailable ; 

'02' = Browser unavailable ; 

'03' = ME unable to read the provisioning data. 

All other values shall be interpreted by the UICC as 'OO'.The coding '00' shall only be used by the ME if no others apply. 

8.1 2.1 1 Additional information for Bearer Independent Protocol 

This subclause applies only if class "e" or "f" is supported. 

For the general result " Bearer Independent Protocol error ", it is mandatory for the ME to provide additional 
information, the first byte of which is defined below: 

'00' = No specific cause can be given; 

'01 ' = No channel available; 

'02' = Channel closed; 

'03' = Channel identifier not valid; 

'04' = Requested buffer size not available; 

'05' = Security error (unsuccessful authentication); 

'06' = Requested SIM/ME interface transport level not available; 

'07' = remote device is not reachable (not present, not physically connected, switched off. . .); 

'08' = Service error (service not available on remote device); 

'09' = Service identifier unknown. 
All other values shall be interpreted by the UICC as '00'. 
The coding '00' shall only be used by the ME if no others apply. 
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8.13 SMSTPDU 



Byte(s) 


Description 


Length 


1 


SMS TPDU tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1)+X+2 


SMSTPDU 


X 



The TPDU is formatted as described in 3G 23.040 [5]. 

Where the TPDU is being sent from the UICC to the ME (to be forwarded to the network), and where it includes a TP- 
Message-Reference which is to be incremented by the ME for every outgoing message, the TP-Message-Reference as 
provided by the UICC need not be the vahd value. TP-Message-Reference shall be checked and corrected by the ME to 
the value described in 3G 23.040 [5]. 



8.14 SS string 



Byte(s) 


Description 


Length 


1 


SS string tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


{Y-1)+3 


TON and NPI 


1 


{Y-1)+4to 
(Y-1)+X+2 


SS or USSD string 


X-1 



TON/NPI and SS or USSD control string are coded as for EFadn^ where the ADN record relates to a Supplementary 
Service Control string. See TS 31.102 [14] for the coding of EFadn- 



8.15 Text string 



Byte(s) 


Description 


Length 


1 


Text string tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


{Y-1)+3 


Data coding scheme 


1 


{Y-1)+4to 
(Y-1)+X+2 


Text string 


X-1 



A null text string shall be coded with Length = '00', and no Value part. 

Data coding scheme is coded as for SMS Data coding scheme defined in TS 23.038 [4]. 

8.1 5.1 Coding of text in unpacked format 

This is indicated by the data coding scheme having a value of 8 bit data. Other parts of the data coding scheme shall be 
ignored. 

This string use the SMS default 7-bit coded alphabet as defined in TS 23.038 [4] with bit 8 set to 0. It may or may not 
include formatting characters, but all such formatting characters shall be taken from the set given in the SMS alphabet. 

NOTE: This is exactly the same format as is used for EFadn alpha-identifiers. It is also the same as SMS 
messages that have been "unpacked". 

8.1 5.2 Coding of text in packed format 

This is indicated by the data coding scheme having a value of 7 bit SMS default alphabet. Other parts of the data coding 
scheme shall be ignored. 
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This string shall use the SMS default 7-bit coded alphabet, packed into 8-bit octets, as defined in TS 23.038 [4]. It may 
or may not include formatting characters, but all such formatting characters shall be taken from the set given in the SMS 
alphabet. 

If the total number of characters in the text string equals (8n-l) where n=l,2,3 etc. then there are 7 spare bits at the end 
of the message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the 
carriage return (i.e. <CR>) character shall be used for padding in this situation, as defined in TS 23.038 [4]. 

NOTE: This is the same format as is used in SMS messages to and from the network. 

8.1 5.3 Coding of text in 1 6 bits UCS2 alpinabet format 

This is indicated by the data coding scheme having a value of 16 bit UCS2 alphabet. Other parts of the data coding 
scheme shall be ignored. 

This string shall use the UCS2 alphabet if the UCS2is supported, as defined in TS 23.038 [4]. It may or may not include 
formatting characters, but all such formatting characters shall be taken from the set given in the UCS2 alphabet. 

NOTE: This is the same format as is used in SMS messages to and from the network. 

8.16 Tone 



Byte(s) 


Description 


Length 


1 


Tone tag 


1 


2 


Length = '01' 


1 


3 


Tone 


1 



Tone: 



contents: Tones can be either the standard supervisory tone, as defined in TS 22.001 [22], or proprietary 
tones defined by the ME manufacturer. The code values for proprietary tones shall be supported by the ME. 
If proprietary tones are not supported the ME shall map these codings to tones that it can generate. The tones 
to be used are left as an implementation decision by the manufacturer; 

coding: 

standard supervisory tones: 

- 'Or Dial tone; 

'02' Called subscriber busy; 
'03' Congestion; 

- '04' Radio path acknowledge; 

- '05' Radio path not available / Call dropped; 

- '06' Error / Special information; 
'07' Call waiting tone; 

'08' Ringing tone. 
- ME proprietary tones: 
'10' General beep; 

'ir Positive acknowledgement tone; 
'12' Negative acknowledgement or error tone; 
'13' Ringing tone as selected by the user for incoming speech call; 
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'14' Alert tone as selected by the user for incoming SMS. 
All other values are reserved. 



8.17 USSD string 



Byte(s) 


Description 


Length 


1 


USSD string tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3 


Data coding scheme 


1 


{Y-1)+4to 
(Y-1)+X+2 


USSD string 


X-1 



The Data coding scheme is coded as for Cell Broadcast defined in TS 23.038 [4]. The coding of the USSD string is 
defined in 3G 22.030 [2]. 

8.18 File List 



Byte(s) 


Description 


Length 


1 


File List tag 


1 


2to(Y-1)+2 


Length (X) of bytes following 


Y 


(Y-1)+3 


Number of files (n) 


1 


{Y-1)+4to 
(Y-1)+X+2 


Files 


X-1 



Number of files: 

this is the number of files that will be described in the following list. 

Files: 

full paths are given to files. Each of these shall be at least 4 octets in length (e.g. '3F002FE2' or 
'3F007F206FAD'). Each entry in the file description is composed of two bytes, where the first byte identifies 
the type of file (see 3G TS 31.101 [13]). 

The path '3F007FFF' indicates the relevant USIM Application dedicated file. 

An entry in the file description shall therefore always begin with '3FXX'. There can be any number of Dedicated File 
entries between the Master File and Elementary File. There shall be no delimiters between files, as this is implied by the 
fact that the full path to any EF starts with '3FXX' and ends with an Elementary type file. 



8.19 Location Information 



Byte(s) 


Description 


Length 


1 


Location Information tag 


1 


2 


Length = '07' 


1 


3-5 


IVIobile Country & Network Codes (MCC & MNC) 


3 


6-7 


Location Area Code (LAC) 


2 


8-9 


Cell Identity Value (Cell ID) 


2 



The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the cell ID are 
coded as in 3G 24.008 [9]. 
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8.20 IMEI 



Byte(s) 


Description 


Length 


1 


IMEI tag 


1 


2 


Length = '08' 


1 


3-10 


IMEI of the ME 


8 



The IMEI is coded as in 3G 24.008 [9]. 



8.21 Help Request 



Byte(s) 


Description 


Length 


1 


Help Request tag 


1 


2 


Length = '00' 


1 



8.22 Network Measurement Results 

This information is only available when the ME is connected to a GSM access network. 



Byte(s) 


Description 


Length 


1 


Network Measurement Results tag 


1 


2 


Length = '10' 


1 


3- 18 


Network Measurement Results 


16 



The Network Measurement Results are coded as for the Measurement Results information element in TS 44.018 [28], 
starting at octet 2 (the lEI is removed, as this information is duplicated by the data object tag). 

8.23 Default Text 

The coding of this data object is the same as for the Text String data object (see subclause 8.15) with the exception that 
the Default Text tag has a specific value (see subclause 9.3). 

8.24 Items Next Action Indicator 



Byte(s) 


Description 


Length 


1 


Items Next Action Indicator tag 


1 


2 


Length (X) 


1 


3 to 3+X-1 


Items Next Action Indicator list 


X 



Contents: Each item of a list of items has a next action indicator coded on one byte. The length of the Items Next 
Action Indicator list shall be the number of items of the list of items (X shall be the number of items in the list). 
The order of each item next action indicator, shall reflect the order o the items in the list of items. 

The Item Next action indicator gives the possible actions that will be initiated by the UICC in case of selection by the 
user. 

Coding: If the value is equal to '00' or if the value is reserved (that is, value not listed), the ME shall ignore the 
next action indicator type. 

See subclause 9.4 for further information. 
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EXAMPLE: For the following list of items: 

- item#l; 
item #2; 

- item #3; 

item #n. 
The Items Next Action Indicator (NAI) shall be as follows: 



Tag Length NAI#1 NAI#2 NAI#3 



NAI#n 



8.25 Event list 



Byte(s) 


Description 


Length 


1 


Event list tag 


1 


2 to Y+1 


Length (X) of bytes following 


Y 


Y+2to 
X+Y+1 


Event list 


X 



Event list: 

contents: A list of events, of variable length. Each byte in the list defines an event. Each event type shall not 
appear more than once within the list; 

coding: Each byte in the event list shall be coded with one of the values below: 

- '00' = MT call; 

'01 ' = Call connected; 

'02' = Call disconnected; 

'03' = Location status; 

'04' = User activity; 

'05' = Idle screen available; 

'06' = Card reader status; 

'07' = Language selection; 

'08' = Browser termination; 

'09' = Data available; 

'OA' = Channel status; 

'OB' = Access technology changed; 

'OC = Display parameters changed; 

'OD' = Local connection. 



8.26 Cause 



Byte(s) 


Description 


Length 


1 


Cause tag 


1 


2 


Length (X) of bytes following. X=0, or 2 < X < 30. 


1 


3 to X+2 


Cause 


X 



The Cause data object is coded as for the Cause call control information element in 3G 24.008 [9], starting at octet 3 
(the lEI and Length information are removed, as this information is duplicated by the data object tag and length). 
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Radio Link Timeout is indicated by the Cause data object having a value part of zero length (only the Tag and Length 
components are sent). 

8.27 Location status 



Byte(s) 


Description 


Length 


1 


Location status tag 


1 


2 


Length (X) of bytes following 


1 


3 


Location status 


1 



Location status: 

contents: this data object indicates the current service state of the UE: 

"normal service" shall indicate that the UE is in a state where all requests for services are treated 
normally; 

"limited service" shall indicate that the UE is in a state where only emergency call services are offered; 

"no service" shall indicate that the UE is in a state where no services are offered. 

coding: Each byte in the event list shall be coded with one of the values below: 

'00' = Normal service; 

'01 ' = Limited service; 

'02' = No service. 



8.28 Transaction identifier 



Byte(s) 


Description 


Length 


1 


Transaction identifier tag 


1 


2 


Length (X) of bytes following 


1 


3 to X+2 


Transaction identifier list 


X 



Transaction identifier list: 

contents: A list of transaction identifiers, of variable length. Each byte in the list defines a transaction 
identifier. Each transaction identifier shall not appear more than once within the list; 

coding: Each byte in the transaction identifier list shall be coded as defined below: 

- bits 1 to 4 = RFU; 

- bits 5 to 7 = TI value; 

- bit 8 = TI flag. 

TI value and TI flag are coded as defined in 3G 24.007 [8]. 

8.29 BCCH channel list 

This information is only available when the ME is connected to a GSM access network. 



Byte(s) 


Description 


Length 


1 


BCCH channel list tag 


1 


2 


Length (X) of bytes following 


1 


3 to X+2 


BCCH channel list 


X 
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BCCH channel list: 

contents: the list of absolute RF channels for BCCH carriers, as known by the ME from the SYSTEM 
INFORMATION messages. The BCCH channel list is composed of one to three BCCH channel sub lists, 
each sub list is derived from the set of frequencies defined by reference neighbour cells description 
information element or elements. In the latter case the set is the union of the different subsets defined by the 
neighbour cells description information elements (see TS 44.018 [28]). The length of the BCCH channel list 
field depends on the length of the received BCCH channel list derived from the different SYSTEM 
INFORMATION messages to be considered. 

coding: Each ARFCN is represented by 10 bits. Spare bit(s) are to be filled with 0. 



Byte1 
Byte 2 
Byte 3 



Bit 8 Bit 7 Bit 6 


Bits Bit 4 Bit 3 Bit 2 


Biti 


ARFCN#1 (high part) | 


ARFCN#1 (low part) 


ARFCN#2 (high part) 




ARFCN#2 (low part) 


ARFCN#3 (high part) 





Byte X-1 
ByteX 



ARFCN#m-1 (low part) 



ARFCN#m (low part) 



ARFCN#m (high part) 



Spare bit 
(0) 



Spare bit 

(0) 



8.30 Call control requested action 



Byte(s) 


Description 


Length 


1 


Call control requested action tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1)+X+2 


Call control requested action 


X 



Call control requested action: 

contents: The action given in response to the ENVELOPE (CALL CONTROL). It may contain, in the same 
order as given by the UICC, the address or SS string, the capability configuration parameters, the called party 
sub-address and the alpha identifier; 

coding: as described in subclause 7.3.1.6, starting with the first optional element given in the response data to 
the ENVELOPE (CALL CONTROL). 

8.31 Icon Identifier 



Byte(s) 


Description 


Length 


1 


Icon identifier tag 


1 


2 


Length = '02' 


1 


3 


Icon qualifier 


1 


4 


Icon identifier 


1 



Icon qualifier: 

contents: The icon qualifier indicates to the ME how the icon is to be used; 

coding: 

- bit 1: = icon is self-explanatory, i.e. if displayed, it replaces the alpha identifier or text string; 

1 = icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the alpha 
identifier or text string. 



bits 2-8 



: RFU. 
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Icon identifier: 

contents: The icon identifier addresses a record in EFimg as defined in TS 31.102 [14]; 
- coding: Binary. 



8.32 Item Icon Identifier list 



Byte(s) 


Description 


Length 


1 


Items Icon identifier tag 


1 


2 


Length (X) of bytes following 


1 


3 


Icon list qualifier 


1 


4 to 4+X-2 


Icon identifier list 


X-1 



Icon list qualifier: 

contents: The icon list qualifier indicates to the ME how the icons are to be used; 
coding: 

- bit 1: = icon is self-explanatory, i.e. if displayed, it replaces the item text; 

1 = icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the item 
text. 

- bits 2-8 = RFU. 

All icons in the list shall be treated in the same manner by the ME, i.e. either none of the icons in this list are displayed, 
or for each item its related icon is displayed. 

Icon identifier list: 

contents: 

each item of a list of items has an icon identifier coded on one byte. The length of the Items icon 
identifier list shall be the number of items of the list of items (X-1 shall be the number of items in the 
list). The order of each item icon identifier, shall reflect the order of the items in the list of items; 

each icon identifier addresses a record in EFjmg as defined in 3G TS 31.102 [14]. 

coding: Binary. 



EXAMPLE: 



For the following list of items: 

- item#l; 
item #2; 

- item #3; 



item #n. 
The Items icon identifier list shall be as follows. 



Tag 


Length 


icon 
identifiers 1 


icon 
identifier#2 


icon 
identifier#3 




icon 
identifier#n 



8.33 Card reader status 



Byte(s) 


Description 


Length 


1 


Card reader status tag 


1 


2 


Length 


1 


3 


Card reader status 


1 



Card reader status: 
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contents: 

this contains the identity of the card reader, and flags to indicate the status of the reader with respect to: 

whether the card reader is removable or permanently connected; 

whether the card reader is present (this can only be false if the card reader is removable); 

whether the card reader present accepts lD-1 size cards (this can only be true if the card reader is 
present); 

whether there is a card present in the card reader (this can only be true if the card reader is present); 

whether power is being applied to the card (this can only be true if a card is present). 

coding: 

the value of this byte indicates the identity and status of a card reader: 

- bits 1-3 = identity of card reader x. 

- bit 4 = Card reader is not removable; 

1 = Card reader is removable. 

- bit 5 = Card reader is not present; 

1 = Card reader is present. 

- bit 6 = Card reader present is not lD-1 size; 

1 = Card reader present is lD-1 size. 

- bit 7 = No card present; 

1 = Card is present in reader. 

- bit 8 = No card powered; 

1 = Card in reader is powered. 

8.34 Card ATR 



Byte(s) 


Description 


Length 


1 


Card ATR tag 


1 


2 


Length (X) of bytes following 


1 


3 to (X+2) 


ATR 


X 



ATR: 

contents: 

this is the Answer To Reset returned by the card, 
coding: 
- the coding of the Answer To Reset is defined in ISO/lEC 78 1 6-3 [ 1 6] . 
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8.35 C-APDU 



Byte(s) 


Description 


Length 


1 


C-APDU tag 


1 


2to(Y+1) 


Length (X) of bytes following (Y = 1 or 2) 


Y 


Y+2 


Command class CLA 


1 


Y+3 


Command instruction code INS 


1 


Y+4 


P1 parameter 


1 


Y+5 


P2 parameter 


1 


Y+6 


Lc (optional) 


Oor1 


(Y+7) to 
(Y+X) 


Data (optional) 


Lc 


Y+X+1 


Le (optional) 


Oor1 



This object contains the command APDU for Card x in the format defined in ISO/IEC 7816-4 [17]. Command class 
CLA, instruction code INS, PI and P2 parameters, Lc, Data and Le are coded as defined in ISO/IEC 7816-4 [17]. 
Extended lengths are not supported. 

Note: The maximum size of the value part of this Simple TLV (value of X) is limited to 241 bytes, so the maximum 
length for the Data (value of Lc) in a Case 3 type of APDU is 236 bytes. 

8.36 R-APDU 



Byte(s) 


Description 


Length 


1 


R-APDU tag 


1 


2 to 
Y+1 


Length (X) of bytes following (Y = 1 or 2) 


Y 


Y+2 to Y+X-1 


R-APDU data (optional) 


X-2 


Y+X 


Status word SW1 


1 


Y+X+1 


Status word SW2 


1 



This object contains the response APDU from Card x in the format defined in ISO/IEC 7816-4 [17]. The R-APDU data 
and status words SWl and SW2 are coded as defined in ISO/IEC 7816-4 [17]. It is possible for no R-APDU data to be 
present; this is indicated by the length of the data object. 

Note: The maximum size of the value part of this Simple TLV (value of X) is limited to 239 bytes, so the maximum 
length of the R-APDU data is 237 bytes. 

8.37 Timer identifier 



Byte(s) 


Description 


Length 


1 


Timer identifier tag 


1 


2 


Length='01' 


1 


3 


Timer identifier 


1 



Timer identifier: 

contents: identifier of a timer; 
coding: 

'Or Timer 1; 

'02' Timer 2; 

'03' Timer 3; 
- '04' Timer 4; 

'05' Timer 5; 
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- '06' Timer 6; 

'07' Timer 7; 

- '08' Timer 8. 
All other values are reserved 

8.38 Timer value 



Byte(s) 


Description 


Length 


1 


Timer value tag 


1 


2 


Length='03' 


1 


3-5 


Timer value 


3 



Timer value: 

contents: value of a timer, expressed using the format hour, minute, second; 
coding: 

- byte 3: hour; this byte is coded exactly in the same way as the hour field of the TP-Service-Centre-Time- 
Stampin3G23.040[5]; 

- byte 4: minute; this byte is coded exactly in the same way as the minute field of the TP-Service-Centre- 
Time-Stamp in 3G 23.040 [5]; 

- byte 5: second; this byte is coded exactly in the same way as the second field of the TP-Service -Centre- 
Time-Stamp in 3G 23.040 [5]. 



8.39 Date-Time and Time zone 



Byte(s) 


Description 


Length 


1 


Date-Time and Time zone tag 


1 


2 


Length = '07' 


1 


3 to 9 


Date-Time and Time zone 


7 



The Date-Time and Time zone is coded as for the Time Zone and Time information element in 3G 24.008 [9], starting 
at octet 2 (i.e. 1 byte for year, month, day, hour, minute, second and time zone). Each byte is encoded in exactly the 
same way as the corresponding field of the TP-Service-Centre-Time-Stamp in 3G 23.040 [5]. For the time zone field, 
'FF' indicates an unknown value. 



8.40 AT Command 



Byte(s) 


Description 


Length 


1 


AT Command tag 


1 


2to(Y-1)-H2 


Length (X) 


Y 


{Y-1)+3to 
{Y-1)+3-i-X-1 


AT Command string 


X 



Contents: The AT Command string is structured exactly as the AT Command line as defined in 3G 27.007 [12], 
which may contain single or concatenated AT commands. 
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8.41 AT Response 



Byte(s) 


Description 


Length 


1 


AT Response tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1)+3+X-1 


AT Response string 


X 



Contents: The AT Response string is structured exactly as the response to a command Hne as defined in 

3G 27.007 [12], which may contain single or concatenated responses appropriate to the issued AT command. 

If the AT Response string is longer than the maximum length capable of being transmitted to the UICC then the 
AT Response string shall be truncated to this length by the ME. 



8.42 BC Repeat indicator 



Byte(s) 


Description 


Length 


1 


BC repeat indicator tag 


1 


2 


Length 


1 


3 


BC repeat indicator values 


1 



Contents: The BC repeat indicator is structured exactly as defined in 3G 24.008 [08], which may be alternate 
mode or sequential mode. 

Coding: 

'Or = Alternate mode; 

- '03' = Sequential mode. 



8.43 Immediate response 

This TLV object is used in the sustained DISPLAY TEXT command. 



Byte(s) 


Description 


Length 


1 


Immediate response tag 


1 


2 


Length='00' 


1 



8.44 DTIVIF string 



Byte(s) 


Description 


Length 


1 


DTIVIF String tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1)+3+X-1 


DTIVIF string 


X 



Contents: 

the DTMF string which can be single or multiple characters is coded in BCD, in the same way as the Dialling 
number string defined for EFADNin TS 31.102 [14]. It may include extended BCD coding. There is no need 
for a DTMF control digit separator at the beginning of the string, but if present it shall be interpreted as 
PAUSE. 



£75/ 



3GPP TS 31.111 version 4.3.0 Release 4 



121 



ETSI TS 131 111 V4.3.0 (2001-06) 



8.45 Language 



Byte(s) 


Description 


Length 


1 


Language tag 


1 


2 


Length = '02' 


1 


3-4 


Language 


2 



Coding: 



each language code is a pair of alpha-numeric characters, defined in ISO 639 [19]. Each alpha-numeric 
character shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in TS 23.038 [4] 
with bit 8 set to 0. 



8.46 Timing Advance 



This information is only available when the ME is connected to a GSM access network. 



Byte(s) 


Description 


Length 


1 


Timing Advance tag 


1 


2 


Length = '02' 


1 


3 


IVIE Status 


1 


4 


Timing Advance 


1 



Coding of ME status: 

- '00' = ME is in the idle state; 

'01' = ME is not in idle state; 

'02' to'FF'= reserved values. 

The Timing Advance is coded as for the Timing Advance information element in TS 44.018 [28], starting at octet 2 (the 
lEI is removed, as this information is duplicated by the data object tag). 



8.47 Browser Identity 



Byte(s) 


Description 


Length 


1 


Browser identity tag 


1 


2 


Length (1) 


1 


3 


Browser Identity 


1 



Coding: 

00 = Default Browser shall be used; 
Other values are RFU. 



8.48 URL 



Byte(s) 


Description 


Length 


1 


URL tag 


1 


2to(Y+1) 


Length (X) 


Y 


(Y+2) to 
(Y+1 + X) 


URL 


X 



A null URL shall be coded with Length = '00', and no Value part. In that case, the ME shall use the default URL. 
Coding: 
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the data used for the URL shall be coded as defined in RFC 1738 [24] on using the "SMS 7bit default 
alphabet" with bit 8 set to . 



8.49 Bearer 



Byte(s) 


Description 


Length 


1 


Bearer tag 


1 


2 to (Y + 1 ) 


Length (X) 


Y 


(Y+2)to(Y + X+1) 


List of bearers in order of priority requested 


X 



The ME shall use this list to choose which bearers are allowed in order of priority. 
Coding of the bearers: 

- '00' = SMS; 

- '01' = CSD; 

- '02' = USSD; 

- '03' = GPRS; 

- '04' to 'FF' = RFU. 

8.50 Provisioning File Reference 



Byte(s) 


Description 


Length 


1 


Provisioning file reference tag 


1 


2to(Y+1) 


Length (X) 


Y 


{Y+2)to(Y + X+1) 


Path to the provisioning file 


X 



NOTE: The path is the concatenation of file identifiers starting from the Master File, e.g. : 3F007F206FXY. . . 

The file shall contain a single unambiguous set of parameters required to make the connection. The content of the file 
shall be consistent with the format defined for provisioning information for the requested type of browser. 

8.51 Browser Termination Cause 



Byte(s) 


Description 


Length 


1 


Browser Termination Cause tag 


1 


2 


Length (1) 


1 


3 


Browser Termination Cause 


1 



Coding: 

00 = User Termination; 

01 = Error Termination. 

8.52 Bearer description 



Byte(s) 


Description 


Length 


1 


Bearer description tag 


1 


2 


Length (X+1) 


1 


3 


Bearer type 


1 


4 to (3+X) 


Bearer parameters 


X 
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Bearer Type coding: 

- '01' = CSD; 

- '02' = GPRS; 

'03' = default bearer for requested transport layer. 
'04' = local link technology independent 

- '05' = Bluetooth 

- '06' = IrDA 

- '07' = RS232 

- '10' = USB 

All other values are reserved. 

8.52.1 Bearer parameters for CSD 

Contents: parameters specific to the bearer. 

In this case X=3. 

NOTE: The default values of the subparameters are manufacturer specific since they depend on the purpose of the 
device and data services provided by it. Not all combinations and values of these subparameters are 
supported by GSM (refer TS 22.002 [1]). 

Coding : The following values are as defined in the TS 27.007 [12] for the select service bearer type "+CBST" 
extended command. They are coded in hexadecimal. 

Coding of Byte 4 - Data rate: same as the "speed" subparameter defined in [12]. 

Coding of byte 5 - bearer service: same as the "name" subparameter defined in [12]. 

Coding of Byte 6 - connection element: same as the "ce" subparameter defined in [12]. 

8.52.2 Bearer parameters for GPRS/Packet Service 

Contents: parameters describing the Quality of Service (QoS) and the type of PDP. This is an element of the PDP 
context. 

In this case X=8. 

Coding : The following values are as defined in the TS 27.007 [12], for the "+CGQREQ" extended command. They are 
coded in hexadecimal. 

Coding of Byte 4 - Precedence class: same as the "precedence" subparameter, defined in [12]. 

Coding of Byte 5 - Delay class: same as the "delay" subparameter, defined in [12]. 

Coding of Byte 6 - Reliability class: same as the "reliability" subparameter, defined in [12]. 

Coding of Byte 7 - Peak throughput class: same as the "peak" subparameter, defined in [12]. 

Coding of Byte 8 - Mean throughput class: same as the "mean" subparameter, defined in [12]. 

Coding of Byte 9 - Packet data protocol type: 

- '02' = IP (Internet Protocol, IETF STD 5); 
all other values are reserved. 
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8.52.3 Default bearer 

Contents: parameters specific to the bearer. 

When the default bearer is present, the ME shall provide its default available bearer parameter configuration. 
X (length of parameters) = 0. 

8.52.4 Bearer parameters for local links (Bluetooth, IrDA, RS232, USB) 

In this case, X= variable. 

Contents: "Service Identifier" and "Service Record" fields as defined in 8.63 and according to the Bearer Type coding 

8.53 Channel data 



Byte(s) 


Description 


Length 


1 


Channel data tag 


1 


2 


Length (X) 


1 


3 to {3+X)-1 


Channel data string 


X 



Contents: 

the Channel data object contains application data read from or written to a specific channel buffer in the ME. 
Coding: 

the Channel data string must be considered by the ME as binary coded on 8 bits. 



8.54 Channel data length 



Byte(s) 


Description 


Length 


1 


Channel data length tag 


1 


2 


Length (1) 


1 


3 


Channel data length 


1 



The Channel data length codes: 

either the number of bytes that are available in a channel buffer (Tx or Rx buffers negotiated during OPEN 
CHANNEL) using TERMINAL RESPONSE. Since the Tx or Rx buffer size can be larger than 255 bytes, 'FF' 
means "more than 255 bytes are available". 

or the number of bytes that are requested in a RECEIVE DATA or transmitted in a SEND DATA command. 

8.55 Buffer size 



Byte(s) 


Description 


Length 


1 


Buffer size tag 


1 


2to(Y+1) 


Length (2) 


Y 


(Y+2) to 
(Y+X+1) 


Buffer size 


2 



The Buffer size codes the number of bytes requested by the UICC in an OPEN CHANNEL command or what the ME 
can offer the UICC (placed in TERMINAL RESPONSE). 
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8.56 Channel status 



Byte(s) 


Description 


Length 


1 


Data tag 


1 


2 


Length (2) 


1 


3 to 4 


Channel status 


2 



- Contents: 

the Channel status is a string of binary coded characters. 
Coding of byte 3: 

- bit 1 to 3: Channel identifier : 1..7; 

Channel identifier means "No channel available". 

- bit 4 to 7: RFU. 

- bit 8: = Link not established or PDP context not activated; 

1 = Link established or PDP context not activated. 
Coding of byte 4: 

'00' = No further info can be given; 

- '01' = Not used; 

- '02' = Not used; 

- '03' = Not used; 

- '04' = Not used; 
'05' = Link dropped; 

all other values are reserved. 

8.57 Card reader identifier 



Byte(s) 


Description 


Length 


1 


Card reader identifier tag 


1 


2 


Length (X) 


1 


3 to (X+2) 


Identifier of card reader 


X 



Identifier of card reader: 

contents: 

this contains manufacturer- specific information to identify the type of card reader being used. 
coding: 

the identifier of card reader is coded in hexadecimal. 
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8.58 Other Address 



Byte(s) 


Description 


Lengtii 


1 


Other address tag 


1 


2 


Lengtii (X) 


1 


3 


Type of address 


1 


4to{4 + X-1) 


Address 


X 



A null Local address shall be coded with Length = '00', and no Value part. In that case, the ME shall request a dynamic 
address. 

Coding of Type of address: according to packet data protocol address in 24.008 [9] 
'21' = IPv4 address 
'97' = IPv6 address 
'others' = reserved 

Coding of address: according to packet data protocol address in 24.008 [9] 

If type of address indicates IPv4, the Address information in octet 4 to octet 7 contains the IPv4 address. Bit 
8 of octet 4 represents the most significant bit of the IP address and bit 1 of octet 7 the least significant bit . 

If type of address indicates IPv6, the Address information in octet 4 to octet 19 contains the IPv6 address. Bit 
8 of octet 4 represents the most significant bit of the IP address and bit 1 of octet 19 the least significant bit. 



8.59 SIM/ME interface transport level 

This subclause applies only if class "e" is supported. 



Byte(s) 


Description 


Length 


1 


SIIVI/ME interface transport level tag 


1 


2 


Length (X+1) 


1 


3 


Transport protocol type 


1 


4 to 5 


Port number 


2 



Transport protocol type coding : 

- '01' : UDP (as defined in RFC 768 [25]) 

- '02' : TCP (as defined in RFC 793 [26]) 
all other value are reserved 

Port number coding : integer 



8.60 AID 



Byte(s) 


Description 


Length 


1 


AID tag 


1 


2 


Length (X) 


1 


3 to (X+2) 


AID 


X 



Contents: 

- application identifier as defined inTS 31.110 [15]. 
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8.61 Access Technology 



Byte(s) 


Description 


Length 


1 


Access Technology tag 


1 


2 


Length = '01' 


1 


3 


Technology 


1 



Technology 

Contents: The ME shall use this information as a mechanism to indicate to the UICC the current access 
technology that it is using. 



Coding: 



'00' GSM 

'01' EIA/TIA-553 

'02' TIA/ElA-136 

'03' UTRAN 

'04' TETRA 

'05' TIA/EIA-95 

'06' TIA/EI A/IS -2000 

All other values are reserved for future use 



8.62 Display parameters 



Byte(s) 


Description 


Length 


1 


Display parameters tag 


1 


2 


Length (3) 


1 


3 to 5 


Parameters list 


3 



Parameters list 

Contents: A list of different information regarding the ME's screen. 

Coding: 

1 bit is used to code parameters supported or not : 
bit = 1 : parameters supported by ME 
bit = 0: parameters not supported by ME 

First byte: (Screen height) 



b8 



hi 



b6 



b5 



b4 



b3 



b2 



bl 



Number of characters supported down the ME display 

as defined in 5.3.1 

RFU, bit = 

Screen Sizing Parameters supported as defined in 

subclause 5.3 



Second byte: (Screen width) 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 

































Number of characters supported across the ME 
display as defined in 5.3.2 
Variable size fonts Supported 



Third byte: (Screen effects) 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Display can be resized as defined in 5.3.3 

Text Wrapping supported as defined in 5.3.4 

Text Scrolling supported as defined in 5.3.5 

RFU 

RFU 

Width reduction when in a menu as defined in 5.3.6 
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8.63 Service Record 

This service record can have different formats that are dependent on the technology they are associated with. 

This object can be used in both directions (ME to UICC or UICC to ME), when a USAT appHcation needs to declare a 
service that it supports (DECLARE SERVICE command) and when USAT application searches for a service (GET 
SERVICE INFORMATION). 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2 to Y+1 


Length (X+2) 


Y 


Y+2 


Local Bearer technology identifier 


1 


Y+3 


Service Identifier 


1 


Y+4to 
Y+X+3 


Service Record 


X 



Local Bearer Technology identifier: 

- '00' = Technology independent: '00' 

- '01' = Bluetooth 

- '02' = IrDA 

- '03' = RS232 

- '04' = USB 

- '05' to 'FF' = RFU 

Service identifier: 

When declaring a service, the UICC associates a Service Identifier to the Service Record. When the Service 
Record TLV is returned in response to GET SERVICE INFORMATION, Service Identifier shall be set to 'FF'. 

- '00' to '07' Service x (0 to 7). Value assigned by USIM. 

'FF' = Service Record related to the service provided by a remote device. 

Other value reserved for future use. 

Service Record: 

When the Service Record field is not meaningful, it shall be assigned the value = '00' 

Technology Independent: RFU 

Bluetooth: 

In Bluetooth a Service record gives all needed information that must be used by a device to connect and 
use this service. 

The full description of the coding of these records is given in the Bluetooth Specification in the SDP 
section [27]. When Service Record is returned in response to GET SERVICE INFORMATION, it 
corresponds to the AttributeList parameter contained in the SDP_ServiceAttributeResponse PDU [27]. 

Strings should be limited to 20 bytes because of the T=0 protocol limitation (255 bytes) and because the 
service record may include several text strings with length possibly higher than 255 bytes. 

- IrDA: RFU 

- RS232: RFU 
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- USB: RFU 

Depending on the proactive command, the parameters of this TLV could be either meaningful or optional. The 
following table indicates in which case the parameters are required. 



Proactive command 


Service Identifier required 


Service Record field required 


DECLARE SERVICE (add) 


Yes 


Yes 


DECLARE SERVICE (delete) 


Yes 


No (value '00' assigned) 


Terminal response of a GET 
SERVICE INFORMATION 


No (value 'FF' assigned) 


Yes 


OPEN CHANNEL (client) 


No (value 'FF' assigned) 


Yes 


OPEN CHANNEL (server) 


Yes 


No (value '00' assigned) 


Local Connection event 


Yes 


No (value '00' assigned) 



8.64 Device Filter 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2 to Y+1 


Length (1+X1+X2+...+Xn) 


Y 


Y+2 


Local Bearer technology identifier 


1 


Y+3 to Y+2+X 


Device Filter 


X 



Local Bearer Technology identifier: see 8.63 
Device filter 

If the Local Bearer Technology Identifier is different from '00', the device filter coding is technology dependent. 

Technology Independent: RFU 

Bluetooth: 

The Device Filter parameter is used to filter the responses to a service search. For Bluetooth, it is a list of 
Class_Of_Device and Class_Of_Device_Mask. 

Device Filter = 

Class_0f_Device_1 [3 bytes], Class_0f_Device_Mask_1 [3 bytes], 

Class_0f_Device_2 [3 bytes], Class_0f_Device_l\/lask_2 [3 bytes], 

Class_Of_Device_n [3 bytes], Class_Of_Device_l\/lask_n [3 bytes]. 

- IrDA: RFU 

- RS232: RFU 

- USB: RFU 



8.65 Service Search 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2 to Y+1 


Length (X+1) 


Y 


Y+2 


Local Bearer technology identifier 


1 


Y+3 to 
Y+X+1 


Service Search 


X 



Local Bearer Technology identifier: see 8.63 
Service search 
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If the Local Bearer Technology Identifier is different from '00', the Service search coding is technology dependent. 

Technology Independent: RFU 

Bluetooth: 

The Service Search field is the ServiceSearchPattern parameter of the SDP_ServiceSearchRequest 
command as defined in [27]. 

- IrDA: RFU 

- RS232: RFU 

- USB: RFU 



8.66 Attribute Information 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2 to Y+1 


Length (X+1) 


Y 


Y+2 


Local Bearer technology identifier 


1 


Y+3to 
Y+X+2 


Attribute Information 


X 



Local Bearer Technology identifier: see 8.63 

Attribute Information 

If the Local Bearer Technology Identifier is different from '00', the Attribute Information coding is technology 
dependent. 

Technology Independent: RFU 

Bluetooth: 

The Attribute Information field consists of a BD_ADDR, followed by the ServiceRecordHandle and the 
AttributelDList pctrameteis of the SDP_ServiceAttributeRequest command as defined in [27]. 

The BD_ADDR is the Bluetooth device address of the device the ME shall connect to. The ME shall use 
the ServiceRecordHandle and the AttributelDList parameters to perform the 
SDP_ServiceAttributeRequest. The ServiceRecordHandle has been previously retrieved with the 
SERVICE SEARCH command. 

- IrDA: RFU 

- RS232: RFU 

- USB: RFU 



8.67 Service Availability 



The Service Availability parameter contains a list of available services that the SERVICE SEARCH command returns. 
This object is formatted according to the local bearer technology identifier byte set in the SERVICE SEARCH 
command arguments. 
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Byte(s) 


Description 


Length 


1 


Service General Information tag 


1 


2 to Y+1 


Length='X1'+ 'X2' + 'X3' +... 'Xn' (n maxi = 7) 


Y 


Y+2toY+X1+1 


Service_1 


X1 


Y+X1+2to 
Y+X1+X2+1 


Service_2 


X2 








Y+X1+...+X(n-1)+2 
to Y+X1+...+Xn+1 


Service_n 


Xn 



Technology Independent: RFU 

Bluetooth: 

For Bluetooth, Service_i = BD_ADDR_i[6 bytes] + ServiceRecordHandle_i[4 bytes] + CoD_i[3 bytes] + 
Device_Name_i[20 bytes], those parameters being defined in [27]. Device Name parameter should be 
truncated to 20 bytes because of the T=0 protocol limitation (255 bytes) and because device name parameter 
length can be higher than 255 bytes. 



Byte(s) 


Description 


Length 


1 


Service General Information tag 


1 


2 to Y+1 


Length='X1'+ 'X2' + 'X3' +... 'Xn' (n maxi = 7) 


Y 


Y+2toY+X1+1 


BD_ADDR + ServiceRecordHandle + CoD + Device_Name 


X1 


Y+X1+2to 
Y+X1 +X2+1 


BDADDR + ServiceRecordHandle + CoD + Device_Name 


X2 








Y+X1+...+X(n-1)+2 
toY+X1+...+Xn+1 


BD_ADDR + ServiceRecordHandle + CoD + Device_Name 


Xn 



IrDA: RFU 
RS232: RFU 
USB: RFU 



8.68 Remote Entity Address 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2 to Y+1 


Length (X+1) 


Y 


Y+2 


Coding Type 


1 


Y+3to 
Y+X+2 


Remote Entity address 


X 



Coding Type: 

'00' : IEEE-802 48-bit address 
'Or to 'FF' are reserved values 

Remote Entity Address: 

according to Coding Type 
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9 Tag values 

This clause specifies the tag values used to identify the BER-TLV and SIMPLE-TLV data objects used in the present 
document. 

9.1 BER-TLV tags in ME to UICC direction 



Description 


Length of tag 


Value 


SMS-PP download tag 




'D1' 


Cell Broadcast download tag 




'D2' 


Menu Selection tag 




'D3' 


Call control tag 




'D4' 


MO Short message control tag 




'D5' 


Event download tag 




'D6' 


Timer expiration 




'D7' 


Reserved for TIA/EIA-1 36 




'DF' 



9.2 BER-TLV tags in UICC TO ME direction 



Description 


Length of tag 


Value 


Proactive UICC command tag 


1 


'DO' 
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9.3 SIMPLE-TLV tags in both directions 



Description 


Length of tag 


Tag value, bits 1-7 
(Range: -or -VE') 


Tag 
(CR and Tag value) 


Command details tag 




'01' 


'01 'or '81' 


Device identity tag 




'02' 


'02' or '82' 


Result tag 




'03' 


'03' or '83' 


Duration tag 




'04' 


'04' or '84' 


Alpha identifier tag 




'05' 


'05' or '85' 


Address tag 




'06' 


'06' or '86' 


Capability configuration parameters tag 




'07' 


'07' or '87' 


Subaddress tag 




'08' 


'08' or '88' 


SS string tag 




'09' 


'09' or '89' 


USSD string tag 




'OA' 


'OA' or '8A' 


SMS TPDU tag 




'OB' 


'OB' or '8B' 


Cell Broadcast page tag 




'OC 


'OC or '8C' 


Text string tag 




'OD' 


'OD' or '8D' 


Tone tag 




'OE' 


'OE' or '8E' 


Item tag 




'OF' 


'OF' or '8F' 


Item identifier tag 




'10' 


'10' or '90' 


Response length tag 




'11' 


'11 'or '91' 


File List tag 




'12' 


'12' or '92' 


Location Information tag 




'13' 


'13' or '93' 


IMEI tag 




'14' 


'14' or '94' 


Help request tag 




'15' 


'15' or '95' 


Network Measurement Results tag 




'16' 


'16' or '96' 


Default Text 




'17' 


'17' or '97' 


Items Next Action Indicator tag 




'18' 


'18' only 


Event list tag 




'19' 


'19' or '99' 


Cause tag 




'1A' 


'1A'or'9A' 


Location status tag 




'1B' 


'1B'or'9B' 


Transaction identifier tag 




'IC 


'1C'or'9C' 


BCCH channel list tag 




'ID' 


'1D'or'9D' 


Icon identifier 




'IE' 


'1E'or'9E' 


Item Icon identifier list 




'IF' 


'1F'or'9F' 


Card reader status tag 




'20' 


'20' or 'AO' 


Card ATR tag 




'21' 


'21'or'A1' 


C-APDU tag 




'22' 


'22' or 'A2' 


R-APDU tag 




'23' 


'23' or 'A3' 


Timer identifier tag 




'24' 


'24' or 'A4' 


Timer value tag 




'25' 


'25' or 'A5' 


Date-Time and Time zone tag 




'26' 


'26' or 'A6' 


Call control requested action tag 




'27' 


'27' or 'A7' 


AT Command tag 




'28' 


'28' or 'A8' 


AT Response tag 




'29' 


'29' or 'A9' 


BC Repeat Indicator tag 




'2A' 


'2A' or 'AA' 


Immediate response tag 




'2B' 


'2B' or 'AB' 


DTMF string tag 




'2C' 


'2C' or 'AC 


Language tag 




'2D' 


'2D' or 'AD' 


Timing Advance tag 




'2E' 


'2E' or 'AE' 


AID tag 




'2F' 


'2F' or 'AF' 


Browser Identity tag 




'30' 


'30' or 'BO' 


URL tag 




'31' 


'31'or'B1' 


Bearer tag 




'32' 


'32' or 'B2' 


Provisioning Reference File tag 




'33' 


'33' or 'B3' 


Browser Termination Cause tag 




'34' 


'34' or 'B4' 


Bearer description tag 




'35' 


'35' or 'B5' 


Channel data tag 




'36' 


'36' or 'B6' 


Channel data length tag 




'37' 


'37' or 'B7' 


Channel status tag 




'38' 


'38' or 'B8' 


Buffer size tag 




'39' 


'39' or 'B9' 


Con 


inued 







£75/ 



3GPP TS 31.111 version 4.3.0 Release 4 



134 



ETSI TS 131 111 V4.3.0 (2001-06) 



Description 


Lengtii of tag 


Tag value, bits 1-7 
(Range: -or -VE') 


Tag 
(CR and Tag value) 


Card reader identifier tag 




'3A' 


'3A' or 'BA' 


not used 




'3B' 


- 


USIIVI/ME interface transport level 




'3C' 


'3C' or 'BC 


not used 




'3D' 


- 


Other address (data destination address) 




'3E' 


'3E'or'BE' 


Access Technology tag 




'3F' 


'3F'or'BF' 


Display parameters tag 




'40' 


'40' or 'CO' 


Service Record 




'41' 


'41'or'C1' 


Device Filter 




'42' 


'42' or 'C2' 


Service Search 




'43' 


'43' or 'C3' 


Attribute information 




'44' 


'44' or 'C4' 


Service Availability 




'45' 


'45' or 'C5' 


Reserved for ETSI SCP 




'46' 




Reserved for TIA/EIA-1 36 




'60' 


'60' or 'EO' 


Reserved for TIA/EIA-1 36 




'61' 


'61' or 'El' 
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9.4 Type of Command and Next Action Indicator 

The table below shows the values which shall be used for Type of Command coding (see subclause 8.6) and Next 
Action Indicator coding (see subclause 8.24). 



Value 


Name 


used for Type of 
Command coding 


used for Next Action 
Indicator coding 


'00' 




- 


- 


'01' 


REFRESH 


X 




'02' 


MORE TIME 


X 




'03' 


POLL INTERVAL 


X 




'04' 


POLLING OFF 


X 




'05' 


SET UP EVENT LIST 


X 




'10' 


SET UP CALL 


X 


X 


'11' 


SEND SS 


X 


X 


'12' 


SEND USSD 


X 


X 


'13' 


SEND SHORT MESSAGE 


X 


X 


'14' 


SEND DTMF 


X 




'15' 


LAUNCH BROWSER 


X 


X 


'20' 


PLAY TONE 


X 


X 


'21' 


DISPLAY TEXT 


X 


X 


'22' 


GETINKEY 


X 


X 


'23' 


GET INPUT 


X 


X 


'24' 


SELECT ITEM 


X 


X 


'25' 


SET UP MENU 


X 


X 


'26' 


PROVIDE LOCAL INFORMATION 


X 




'27' 


TIMER MANAGEMENT 


X 




'28' 


SET UP IDLE MODEL TEXT 


X 


X 


'30' 


PERFORM CARD APDU 


X 


X 


'31' 


POWER ON CARD 


X 


X 


'32' 


POWER OFF CARD 


X 


X 


'33' 


GET READER STATUS 


X 


X 


'34' 


RUN AT COMMAND 


X 




'35' 


LANGUAGE NOTIFICATION 


X 




'40' 


OPEN CHANNEL 


X 


X 


'41' 


CLOSE CHANNEL 


X 


X 


'42' 


RECEIVE DATA 


X 


X 


'43' 


SEND DATA 


X 


X 


'44' 


GET CHANNEL STATUS 


X 


X 


'45' 


SERVICE SEARCH 


X 


X 


'46' 


GET SERVICE INFORMATION 


X 


X 


'47' 


DECLARE SERVICE 


X 




'60' 


Reserved for TIA/EIA-1 36 


X 


X 


'81' 


End of the proactive session 


not applicable 


X 
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10 Allowed Type of command and Device identity 
combinations 

Only certain types of commands can be issued with certain device identities. These are defined below. 



Command description 


Source 


Destination 


CALL CONTROL 


ME 


UICC 


CELL BROADCAST DOWNLOAD 


Network 


UICC 


COMMAND RESULT 


ME 


UICC 


DISPLAY TEXT 


UICC 


Display 


EVENT DOWNLOAD 






- MT call 


Network 


UICC 


- Call connected at near end (MT call) 


ME 


UICC 


- Call connected at far end (MO call) 


Network 


UICC 


- Call disconnected at near end 


ME 


UICC 


- Call disconnected at far end 


Network 


UICC 


- Location status 


ME 


UICC 


- User activity 


ME 


UICC 


- Idle screen available 


Display 


UICC 


- Card reader status 


ME 


UICC 


- language selection 


ME 


UICC 


- data available 


ME 


UICC 


- channel status 


ME 


UICC 


- access technology changed 


ME 


UICC 


- display parameters changed 


ME 


UICC 


- local connection 


Network 


UICC 


GETINKEY 


UICC 


ME 


GET INPUT 


UICC 


ME 


GET READER STATUS 






- if card reader status requested 


UICC 


ME 


- if card reader identifier requested 


UICC 


card reader x 


LANGUAGE NOTIFICATION 


UICC 


ME 


LAUNCH BROWSER 


UICC 


ME 


MENU SELECTION 


Keypad 


UICC 


MO SHORT MESSAGE CONTROL 


ME 


UICC 


MORE TIME 


UICC 


ME 


PERFORM CARD APDU 


UICC 


Card reader x 


PLAY TONE 


UICC 


Earpiece (see note) 


POLLING OFF 


UICC 


ME 


POLL INTERVAL 


UICC 


ME 


POWER ON CARD 


UICC 


Card reader x 


POWER OFF CARD 


UICC 


Card reader x 


PROFILE DOWNLOAD 


ME 


UICC 


PROVIDE LOCAL INFORMATION 


UICC 


ME 


REFRESH 


UICC 


ME 


RUN AT COMMAND 


UICC 


ME 


SELECT ITEM 


UICC 


ME 


SEND DTMF 


UICC 


Network 


SEND SHORT MESSAGE 


UICC 


Network 


SEND SS 


UICC 


Network 


SEND USSD 


UICC 


Network 


SET UP CALL 


UICC 


Network 


SET UP EVENT LIST 


UICC 


ME 


SET UP IDLE MODE TEXT 


UICC 


ME 


SET UP MENU 


UICC 


ME 


SMS-PP DOWNLOAD 


Network 


UICC 


TIMER MANAGEMENT 


UICC 


ME 


TIMER EXPIRATION 


ME 


UICC 


Continued... 
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Command description 


Source 


Destination 


OPEN CHANNEL 


UICC 


ME 


CLOSE CHANNEL 


UICC 


Channel x 


RECEIVE DATA 


UICC 


Channel x 


SEND DATA 


UICC 


Channel x 


GET CHANNEL STATUS 


UICC 


ME 


SERVICE SEARCH 


UICC 


ME 


GET SERVICE INFORMATION 


UICC 


ME 


DECLARE SERVICE 


UICC 


ME 


NOTE: The ME may route the tone to other loudspeakers (external ringer, car kit) if more appropriate. 



1 1 Security requirements 



GSM 03.48 [22] specifies standardised methods of securing the content of appHcation messages. If it is necessary to 
secure appHcation messaging to Toolkit appUcations, then GSM 03.48 may be used. 
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Annex A (normative): 

Support of USAT by Mobile Equipment 

Support of USAT is optional for Mobile Equipment. However, if an ME states conformancy with a specific 3G release, 
it is mandatory for the ME to support all functions of that release. 

The support of letter classes, which specify mainly ME hardware dependent features, is optional for the ME and may 
supplement the USAT functionality described in the present document. If an ME states conformancy to a letter class, it 
is mandatory to support all functions within the respective letter class. 

The table below indicates the commands and functions of the optional letter classes. 



Letter classes 


Command/function description 


a 


Proactive command: GET READER STATUS 
Proactive command: PERFORIVI CARD APDU 
Proactive command: POWER ON CARD 
Proactive command: POWER OFF CARD 
Event download: Card reader status 


b 


Proactive command: RUN AT COMMAND 


c 


Proactive command: LAUNCH BROWSER 
Event download: Browser termination 


d 


Soft key support 


e 


Proactive command: OPEN CHANNEL 
Proactive command: CLOSE CHANNEL 
Proactive command: RECEIVE DATA 
Proactive command: SEND DATA 
Proactive command: GET CHANNEL STATUS 
Event download: Data available 
Event download: Channel status 


f 


Proactive command: SERVICE SEARCH 
Proactive command: GET SERVICE INFORMATION 
Proactive command: DECLARE SERVICE 
Event download: Local connection 
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Annex B (informative): 

Example of DISPLAY TEXT Proactive UICC Command 

Example of DISPLAY TEXT Proactive UICC Command (BER-TLV Data Object). 



Byte# 


Value (Hex) 


Description 


1 


DO 


Proactive UICC command tag 


2 


10 


length 


3 


81 


command details tag 


4 


03 


length 


5 


01 


command number 


6-7 


21 00 


Display text (normal priority, clear message after a delay) 


8 


82 


Device identities tag 


9 


02 


length 


10 


81 


source: UICC 


11 


02 


destination: Display 


12 


8D 


Text string tag 


13 


05 


length 


14 


04 


Data coding scheme ('04'=8-bit default SMS) 


15-18 


55,53,41,54 


text string ("USAT") 
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Annex C (normative): 

Structure of USAT communications 



BER-TLV data 
object 

SIMPLE-TLV 

data object 

Elements within 
the data object 



l..n SIMPLE-TLV objects 



T L 



L.m elements 



T L V 



USAT commands and responses are sent across the interface as BER-TLV data objects. Each APDU shall only contain 
one BER-TLV object. See ISO/IEC 7816-6 [18] for more information on data objects. 



The tag of a BER-TLV is a constant value, length one byte, indicating it is a USAT command. 

The length is coded onto l,or 2 bytes according to ISO/IEC 7816-6 [18]. The table C.l details this coding. 

Table C.I 



Length 


Byte1 


Byte 2 


0-127 


length ('00' to '7F') 


not present 


128-255 


'81' 


length ('80' to 'FF') 



Any length within the APDU limits (up to 255 bytes) can thus be encoded on two bytes. This coding is chosen to 
remain compatible with ISO/IEC 7816-6 [18]. 

Any values for byte 1 or byte 2 that are not shown above shall be treated as an error and the whole message shall be 
rejected. 

The value part of the BER-TLV data object consists of SIMPLE-TLV data objects, as shown in the description of the 
SIMPLE-TLV data objects on individual commands. It is mandatory for SIMPLE-TLV data objects to be provided in 
the order given in the description of each command. New SIMPLE-TLV data objects can be added to the end of a 
command. 

The structure of SIMPLE-TLV tags is defined in the subclause below. 

The M/O/C columns specify whether it is mandatory, optional or conditional for the sender to send that particular 
SIMPLE-TLV data object for compliance with the current version of the present document. The Min (Minimum Set) 
column describes whether it is necessary for the receiver to have received that particular SIMPLE-TLV data object to 
be able to attempt at least the most basic form of this command. The procedure for dealing with incomplete messages is 
described in subclause 6.10. 

'00' and 'FF' are never used as tag values. This is in accordance with ISO/IEC 7816-6 [18]. Padding characters are not 
allowed. 



C.1 SIMPLE-TLV tag format 

SIMPLE-TLV tags can be in one of two formats: single byte and three-byte format. 
The value of the first byte identifies the format used. 



£75/ 



3GPP TS 31.111 version 4.3.0 Release 4 



141 



ETSI TS 131 111 V4.3.0 (2001-06) 



First byte value 


Format 


'00' 


Not used, in accordance with ISO/IEC 7816-6 [18] 


'01' -'7E' 


Single byte 


'7F' 


Three-byte 


'80' 


Reserved for future use 


'81' -'FE' 


Single byte 


'FF' 


Not used, in accordance with ISO/IEC 7816-6 [18] 



The same value in the two formats represent the same data object. 



C.1.1 Single byte format 

The tag is coded over one byte. 



8 


7 


6 


5 1 4 1 3 


2 


1 1 


CR 


Tag value 



CR: Comprehension required for this object. 

Unless otherwise stated, for SIMPLE-TLV data objects it is the responsibility of the UICC application and the ME to 
decide the value of the CR flag for each data object in a given command. 

Handling of the CR flag at the receiving entity is described in subclause 6.10. 



CR 


Value 


Comprehension required 


1 


Comprehension not required 






C.1 .2 Three-byte format 

The tag is coded over three bytes. 



Byte 1 


Byte 2 


Byte 3 


8 


7 


6 


5 1 4 


3 1 2 1 1 


Tag value format = 7F' 


CR 


Tag value 



Tag value format: Byte 1 equal to '7F' indicates that the tag is in the three-byte format. 

CR: Comprehension required for this object. Use and coding is the same as in single byte format. 

Tag value: Coded over 15 bits, with bit 7 of byte 2 as the most significant bit. Range is from '00 01' to '7F FF'. 
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Annex D (informative): 

ME display in proactive UICC session 

Example of the ME display whilst the ME is in a proactive UICC session. 

ME display ME 

[Setup menu being navigated] 



Setup 
Menu list 



Select 
Item list 



Get 
In key 



ME 
Display 



Envelope (Menu Selection) 



UICC 





SW = 91 XX 


► 




Fetch 






Select Item 




Terminal Response 




SW = 91 XX 




Fetch 




Get Inkey 




Terminal Response 


■4 


SW = 90 00 





Figure D.I 
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Annex E (informative): 

Help information feature processing 



The following example shows the use of the commands Menu Selection / Select Item and Get Input in conjunction with 
the help information feature. 



ME 

TFRMIMAI PROFII F 




UICC 

91 XX 




< 


PPTPI-I 




qpT 1 IP N/IFMI 1 CHpIn a\/ailahlp\ 










TFRMIMAI RFCIPDMCIF ICiK^ 




an nn 










FMVFI OPF CN/IFMI 1 C!p| FPTIOM 




91 XX 


help on menu item m) 


< 


ppxpu 




nic:PI AY TFYT CHpJn infn tn itpm m'l 










TFRN/IIMAI RFC:pnMC:p ICtK^ 




Qn nn 


(ME offers menu again and user 
selects item m) 

FM\/FI OPF CMFMI 1 ciFI FPTIOM 






91 XX 

qpi PPT ITFM 


select item m) 

ppxpu 


< 








(Item list under item m, help available) 


TFRK/IIMAI RFC:pr~)MQp 




91 XX 


(Help on item mn in item list under 
item m ) 


< 


ppxpu 




DISPLAY TEXT (Help info to item mn) 








TFRK/IIMAI RFC:pnMC:p ICtK^ 




91 XX 




< 


ppxpu 




Rpnptitinn nf CIFI FPT ITFM 


ppxpu 




< 


(Item list under item m, help available) 
91 XX 

PPT IMPI IT 










TFRMIMAI RFCIPDMCIF 




91 XX 


(Help info required) 


< 


FFTPH 




niQpi AY TFYT CHpIn infn\ 










TFRMIMAI RFC^POMCiF {n[<\ 




91 XX 




< 


FFTPH 




Rpnptitinn nf PPT IMPI IT 










TFRMIMAI RFCiPOMQF (n[<\ 
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Annex F (informative): 
Monitoring of events 



Some of the events monitored through the event download mechanism are reported by the mobile each time the event 
occurs, while other events are reported only once (the ME removes the event type from the current event list once the 
event occurs). This is summarised in the table below. 



Event 


Continuously reported 


Reported once 


MT call 


X 




Call connected 


X 




Call disconnected 


X 




Location status 


X 




User activity 




X 


Idle screen available 




X 


Card reader status 


X 




Language selection 


X 




Data available 


X 




Channel status 


X 




Browser termination 


X 




Access technology changed 


X 




Display parameters changed 


X 




Local connection 


X 
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Annex G (normative): 

Support of Multiple Card Operation 

This annex applies only if class "a" is supported. 

It is intended that MultipleCard commands are an optional extension to the basic USAT functionality in the present 
document. 

The ME is responsible for appropriate protocol management, as defined in ISO/IEC 7816-4 [17]. This includes APDU 
mapping and procedure byte handling. 

If the ME is already powered on and a UICC is active, then, when Card x is inserted, the ME powers on Card x. The 
ME shall identify if Card x contains the UICC application. If it does, GSM 02.17 [21] applies. If it does not contain the 
UICC application, or it is not selected by the user for 3G operation, then the ME powers off Card x. If applicable, the 
ME shall send an event download (card reader status) message to the current UICC. When required, the USAT 
application of the current UICC card shall power on Card x and control communications, through the relevant proactive 
commands. 

When the ME is powered on, the ME locates and selects the preferred UICC card defined in GSM 02.17 [21]. If 
applicable, the ME sends a Terminal Profile command to the UICC. When required, the USAT application issues a Get 
Reader Status proactive command, which gets information on all readers and cards available to the USAT application. 
This procedure also applies if the ME is already powered on with no UICC present, and a card is then inserted. 

When the UICC issues a POWER ON CARD, and the ME successfully receives an Answer To Reset from Card x, the 
ME shall return a successful Terminal Response containing the ATR, even if it does not understand the contents of the 
ATR, or support any of the protocols indicated. 

The ME shall ensure that Card x is deactivated according to ISO/IEC 7816-3 [16]. Where deactivation is not due to a 
POWER OFF CARD proactive command (e.g. card removed, card reader removed, or low battery), the event download 
(card reader status) procedure may also be applicable. 
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Annex H (informative): 

Multiple Card proactive command examples 

This annex applies only if class "a" is supported. 



UICC 



ME 



Card-x 



PERFORM CARD APDU 

PERFORM CARD APDU 



-Terminal Response (R-APDU) 



POWER OFF CARD 

POWER OFF CARD > 

< Terminal Response() 

POWER ON CARD 

POWER ON CARD > 



< Terminal Response (ATR) 

POWER ON CARD > 



< Terminal Response (ATR) 

GET READER STATUS 

GET READER STATUS > 

< Terminal Response (Status of card reader(s)) 



C-APDU > 

< R-APDU 



Deactivate Card x - 



Activate and Reset Card x > 

< Answer to Reset 



Reset Card x > 

i Answer to Reset 



ME scans all possible card reader interfaces 
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Annex I (informative): 

Bearer independent protocol proactive command examples 

This annex applies only if class "e" is supported. 



UICC 



ME 



Network 



OPEN CHANNEL 'immediate link 
establishment' 

OPEN CHANNEL (immediate) - 



< Terminal Response (Channel identifier) 

< ENVELOPE (Channel Status, link established) 

OPEN CHANNEL On demand link 
establishment' and SEND DATA 
'immediately' 

OPEN CHANNEL (on demand) > 

< Terminal Response (Channel identifier) 

SEND DATA (immediate, Data) > 



< Terminal Response (Channel Data Length) 

OPEN CHANNEL On demand link 
establishment' and SEND DATA 'Stored in 
Tx buffer' 

OPEN CHANNEL (on demand) > 

< Terminal Response (Channel identifier) 

SEND DATA (Store, Data) > 

< Terminal Response (Channel Data Length) 

SEND DATA (Store, Data) > 

< Terminal Response (Channel Data Length) 



SEND DATA (Immediate, Data)- 



< Terminal Response (Channel Data Length) 

CLOSE CHANNEL 

CLOSE CHANNEL(Channel identifier) > 

< Terminal Response(OK) 



Set Up Call > 

< OK 



Set Up Call > 

< OK 

Data > 



Set Up Call ■ 



Data- 
Data- 



OK 



Terminate call > 

< OK 
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RECEIVE DATA 



i ENVELOPE (Data available) 

RECEIVE DATA (Channel Data length) > 

< Terminal Response(Data<=Length) 



SEND DATA 'immediately' 

SEND DATA (Immediate, Data) > 

< Terminal Response(Channel Data length) 

SEND DATA 'Stored in Tx Buffer' 

SEND DATA (Store, Data) > 

< Terminal Response(Channel Data length) 

SEND DATA (Store, Data) > 

< Terminal Response(Channel Data length) 

SEND DATA (Immediate, Data) > 

< Terminal Response(Channel Data length) 

GET CHANNEL STATUS 

GET CHANNEL STATUS > 

< Terminal Response (Channel status) 



i Data 



Data > 



Data > 



1 Channel available 



Example for GPRS bearer: 



ICC 



ME 



SGSN 



OPEN CHANNEL 

OPEN CHANNEL (immediate, 
Bearer description(bearertype=GPRS, OoS, PDP 

type=IP), 

Buffer size, APN, SIIVI/ME interface transport level 

(UDP, port p ), data destination address) > 



< Terminal Response (Channel identifier, link 

established, no further information, buffer size) 

< ENVELOPE (Channel status event: Channel 

identifier, link established) 



CLOSE CHANNEL 

CLOSE CHANNEL(Channel identifier) > 

< Terminal Response(OK) 



Attach request > 

< Attach accept 

Activate PDP context Request (Requested PDP 
address, OoS, APN, PDP Type > 

< Activate PDP context Accept (PDP address, 

negotiated OoS, PDP type) 



Deactivate PDP context request > 

< Deactivate PDP context accept 
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RECEIVE DATA 



i ENVELOPE (Data available) 

RECEIVE DATA (Channel Data length) > 

i Terminal Response(Channel Data Length, 

Data<=Length) 

RECEIVE DATA (Channel Data length) > 

< Terminal Response(Channel Data Length, 

Data<=Length) 



RECEIVE DATA (Channel Data length) > 

< Terminal Response(Channel Data Length = 0, 

Data<=Length) 



< Data (one complete SDU received) 



SEND DATA 'Stored in Tx Buffer' 

SEND DATA (Store, Data) 



< Terminal Response(Channel Data length) 

SEND DATA (Store, Data) > 

< Terminal Response(Channel Data length) 



SEND DATA (Immediate, Data) > 

< Terminal Response(Channel Data length = 0) 



GET CHANNEL STATUS 



Data > 



GET CHANNEL STATUS > 

-Terminal Response (Channel status) 



1 Channel available 
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Annex J (informative): 
WAP References 



[1] WAP specifications: URL : http://www.wapforum.org/ . 

[2] WAP Smart card provisioning specification: URL : http://www.wapforum.org/ . 

Definitions: 

WAE User Agent : any software or device that interprets WML, WMLScript. 

WMLScript : a scripting language used to run a program in the mobile device. 

Abbreviations: 

WAE Wireless Application Environment 

WAP Wireless Application Protocol 

WML Wireless Markup Language 
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Annex K (informative): 

Use of USAT Bearer independent protocol for local links 

Bluetooth case 

Bluetooth services to be run by the USIM should be developed so that he access to their service record is open and does 
not necessitate any security mechanism (no authentication or encryption). 

K.1 Service Search command 

The Local Bearer Technology Identifier is Bluetooth. Service Search consists for the ME in first performing a device 
discovery of the devices that conform to the Device Filter (inquiry responses are filtered according to the list of Class of 
Device given in the Device Filter); then performing an SDP_ServiceSearchRequest, as defined in [27], on each device 
to check the support of the given service. The ME shall then return the Service Availability data object which is a list of 
BD_ADDR, ServiceRecordHandle, CoD and Device Name. 

Note for Handset Manufacturers: 

As the mobile is not always connected to other devices present in the remote environment (e.g. Bluetooth), when 
performing a service search, it is up to the ME to set a procedure that allows: 

A "scan" of the environment to discover new devices; 

A connection to Service Discovery Servers of discovered devices; 

A match with the requested service to set up the response to the USAT application. 

K.2 Get Service Information command 

The Local Bearer Technology Identifier is Bluetooth, GET SERVICE INFORMATION consists for the ME in 
connecting to a specific device and performing a SDP_ServiceAttributeRequest PDU as defined in [27]. The ME shall 
then return the Service Record data object. 

When performing a GET SERVICE INFORMATION, it is up to the ME to set up a connection with the requested 
device and perform the SDP exchange. 

K.3 OPEN CHANNEL command 

If the SIM/ME interface parameter is not present, the SIM/ME interface is the bearer level which is the RFCOMM 
level. 

The Remote Entity Address shall be present and shall be the BD_ADDR of the remote device. 
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Example: Interaction - USAT client case: 



UICC 



ME 



Remote entity 



SERVICE RETRIEVAL 



SERVICE SEARCH(DeviceFilter, ServiceSearch) 



For each device 
In the environment 



r 



< 



V 



< Terminal Response (ServiceAvailability{list of 

[BD_ADDR, Service_Handle, CoD, Device_name]) 



Inquiries > 

Inquiry Responses (BD_ADDR, CoD) 

Page (BD_ADDR) > 

< Page Response () 

Name Request > 



< Name Response (Device Name) 

Connection Request > 

< Connection Response () 

SDP_ServiceSearch Request > 

< SDP_ServiceSearch Response () 



DETAILED INFORMATION ON SERVICE 

GET SERVICE INFORMATION 

{Attributelnformation(BD_ADDR, 

SDP_ServiceAttributeSearchReq (ServiceHandle, ...)) 



-Terminal Response (Service Record]) 



Page (BD_ADDR) > 

< Page Response () 

Connection Request > 

< Connection Response () 

SDP_ServiceAttributeSearch Request > 

< SDP_ServiceAttributeSearch Response () 



OPEN CHANNEL 'active link establishment' 



OPEN CHANNEL (active flag , Service Identifier = FF, 
Service Record PDU) > 



< Terminal Response (Channel identifier) 

RECEIVE DATA 

< ENVELOPE (Data available, Channel Identifier) 

RECEIVE DATA (Channel identifier, Channel Data 

length) > 

< Terminal Response(Data<=Length) 



Page (BD_ADDR) > 

< Page Response () 



Connection Request > 

Connection Response () 



■ Data (remote connection request) 
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Annex L (informative): 

Bluetooth Service Discovery protocol 

The service Bluetooth protocol is used to provide a way to get information of services offered by device present in a 
same Bluetooth environment. Each device providing a service must have a SDP Server software that can be connected 
by any other device. This connection is set-up by a SDP Client software and is performed in a one to one process. 



SDP 

Client 
Application 



SDPServer 
Application 



SDP Client API 



SDP Server API 



SDP 
Client 




Service 

records 

Database 



The server maintains a Service Record Database that describe the characteristics of services associated with the server. 
Each service record contains information about a single service. A client may retrieve information from a service record 
maintained by the SDP Server by issuing an SDP request. 

The notion of Service Record need to be presented here for a better understanding of function set introduced. We have 
seen that the SDP server must maintain a list of record describing services present on the device. 

The service record consists entirely of a list of service attributes. 

A service record handle is a 32-bit number that uniquely identifies each service record within an SDP server. 



L1 



Service Attribute: 



Each service attribute describes a single characteristic of a service. Each service attribute consists of two components: 
an attribute ID and an attribute value. The set of attributes characterising one service are gathered in a service record. 
The table below introduces examples of attributes that can be used in a service record. 



Attribute 


Description 


ServiceClassldList 


Identifies the type of service represented by a service record. In other 
words, the list of classes of which the service is an instance 


Service ID 


Uniquely identifies a specific instance of a service 


ProtocolDescriptorList 


Specifies the protocol stack(s) that may be used to utilise a service 


ProviderName 


The textual name of the individual or organisation that provides a service 


ServiceName 


A text string containing a human readable name for the service 


ServiceDescription 


A text string describing the service 
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The USAT application shall provide such record to the SDP server in order to become reachable by any other device. 
Information shall be presented to the SDP server in the good format (see Bluetooth specification [27]) to be easily 
integrated in its own Service record Database. 

Following is a brief description of the way by which a USAT application could retrieve a service residing on another 
device. 

A Bluetooth device can perform a search by Patterns (Service UUID or Attributes) or by browsing. A service browsing 
must interact with the user. We here prefer that the USAT application simply sends a search that the SDP Client ME 
software will perform. The USAT application will perform a Service Search with a service search pattern. A service 
search pattern is a list of UUIDs used to locate matching service records. The USAT application will prepare PDU(s) 
that the SDP client software will just have to push to L2CAP layer and to SDP Server software residing on another 
device. Once the USAT gets the list of services available, it can get further information on the services and then select 
one to perform an OPEN CHANNEL. 
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Annex M (informative): 

Use of USAT Bearer independent protocol for local links, 

server case 

This annex applies if classes "e" and "f are supported. 



UICC 



ME 



Remote entity 



SERVICE DECLARATION 



DECLARE SERVICE (add flag, Service Identifier = X, 

Service Record PDU) > 

< Terminal Response () 



OPEN CHANNEL as server 



< Envelope (Local connection) 

OPEN CHANNEL (Service Identifier = X, Service 

Record PDU=00) > 

< Terminal Response (Channel identifier) 



-connection request on service identifier X 



RECEIVE DATA 



i ENVELOPE (Data available, Channel Identifier) 

RECEIVE DATA (Channel identifier, Channel Data 

length) > 

< Terminal Response(Data<=Length) 



■ Data (remote connection request) 



SERVICE REMOVAL 



DECLARE SERVICE (delete flag. Service Identifier, 

Service Record PDU=00) > 

< Terminal Response () 
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Annex N (informative): 
Change history 



The table below indicates all change requests that have been incorporated into the present document since it was 
initially approved by 3GPP TSG-T. 



Change history | 


Date 


TSG# 


TSG Doc 


CR 


Rev 


Cat 


Subject/Comment 


Old 


New 


2000-04 


TP-07 


TP-000055 








Version 2.1 .0 was approved at TSG-T #07 


2.1.0 


3.0.0 


2000-07 


TP-08 


TP-000096 


001 




F 


Release 99 alignement of 31.111 with GSM 11.14 


3.0.0 


3.1.0 




003 




F 


Correction of SAT commands for using GPRS in bearer 
independent protocol feature 




004 




F 


Clarification of ME/SIM interface for bearer independent 
protocol feature 


2000-10 


TP-09 


TP-000154 


005 




F 


Correction of Profile Download regarding USAT service 
table 


3.1.0 


4.0.0 


TP-000154 


006 




C 


Modification of GET INKEY 


TP-000154 


007 




C 


DTMF issues 


TP-000154 


008 




F 


correction to GET INPUT regarding number of response 
string variables 


TP-000154 


009 




F 


Clarification for Alpha Identifier in PLAY TONE 


TP-000154 


010 




F 


EVENT DOWNLOAD-MT call : correction of the sub- 
address description 


TP-000154 


Oil 




B 


Addition of a Technology Indicator Tag in a Terminal 
Response message 


2000-12 


TP-10 


TP-000202 


013 




A 


Get Reader Status - correction to card identifier tag 


4.0.0 


4.1.0 


TP-000202 


014 




B 


New event for display parameters 


TP-000202 


016 




A 


General Clarification and Correction 


TP-000202 


018 




A 


Clarification of command qualifier related to LAUNCH 
BROWSER 


TP-000202 


020 




A 


Modification of general result for proactive command 
with user confirmation 


TP-000202 


022 




A 


Clarification of bearer independent related to GPRS 


TP-000202 


024 




A 


Correction to device identity coding 


2001-03 


TP-11 


TP-010039 


026 




A 


Correction of TERMINAL PROFILE 


4.1.0 


4.2.0 


TP-010039 


027 




F 


Addition of UTRAN to the technology indicator 


TP-010039 


028 




C 


Introduction of additional Access Technology Indicator 
values" 


TP-010039 


032 




A 


Correction of reference from GSM 02.40 to TS 22.001 


TP-010039 


033 




B 


Addition of variable timeout to the Display Text 
command 


TP-010039 


034 




F 


Correction to display parameters tag 


TP-010039 


035 




B 


Use of USAT Bearer independent protocol for local links. 
Client use case. 


TP-010039 


036 




B 


Use of USAT Bearer independent protocol for local links, 
server use case. 


TP-010039 


037 




A 


Correction of Annex A: Support of USAT by Mobile 
Equipment 


TP-010039 


038 




F 


Alignment with GSM 1 1 .14 for reserved TIA/EIA-1 36 
tags" 


TP-010039 


039 




B 


Addition of variable timeout to Getlnkey command 


TP-010039 


040 




C 


Precisions on the PlayTone command 










Implementation of CRs 035 & 036 was corrected 


4.2.0 


4.2.1 


2001-06 


TP-12 


TP-010151 


042 




A 


Correction to NMR functionnality (and BCCH list & TA) 


4.2.1 


4.3.0 


TP-010151 


044 




A 


General corrections 


TP-010151 


046 




A 


Clarification of min and max length for GET INPUT 


TP-010151 


048 




A 


Limitation of data field in the C-APDU and R-APDU data 
object 


TP-010151 


050 




A 


Correction of Annex 1 (Bearer independant protocol 
examples) 
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Document history 


V4.2.1 


March 2001 


Publication 


V4.3.0 


June 2001 


Publication 
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